uint vs uint256 -> Small Solidity detail that can cause big Heisenbug

If we use delegate call in Solidity there is one small detail that can cause very hard to locate bug.

In normal situation when we declare variable as uint256 we typically write just uint public number; syntax. And this will be seen as alias for uint256 public number;. It is more efficient to write just uint and it is type of number most in use. And from that productivity point of view absolutely make sense to use unspecified uint instead of uint256. But if we want to make delegatcall and we specify just uint then we will induce small, totally transparent and hard to catch heisenbug.

Here is example:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.9;
contract TestTemplate {

    uint public amount;
    address public sender;

    function writeTo (uint _amount) public {
        amount = _amount;
        sender = msg.sender;
    }
}

And now contract from which we make that delegatecall:

contract TestTwo {

    uint public amount;
    address public sender;


    function writeTo(address _to, uint _amount) public  { 
        (bool success, bytes memory data) = _to.delegatecall(abi.encodeWithSignature("writeTo(uint)", _amount));        
    }
}

This _to.delegatecall(abi.encodeWithSignature("writeTo(uint)", _amount)); is crucial for generating this type of bugs. Because if we use just uint, what is widely adopted practice of using allices instead of real uint256, we are in trouble.

But instead if we use: _to.delegatecall(abi.encodeWithSignature("writeTo(uint256)", _amount));
we will live happy long after.

Now from outside perspective it looks as arbitrary decision that on the level of language we can use one way to declare variable in one case and second and more strict one in another. Most probably there are some deeper language designee reasons why this is the case. But from practical point of view this can be a bit tricky. That is why for consistency reason I start to use only uint256 all across the bord avoiding this type of issues entirely.