Compiler error on attempting to use hexadecimal literals of length 39-41 as integers

[barakman]

Description

Attempting to use a hexadecimal literal of length 39 as integer leads to the following compilation errors:

• SyntaxError: This looks like an address but is not exactly 40 hex digits. It is 39 hex digits. If this is not used as an address, please prepend '00'.
• TypeError: Built-in binary operator / cannot be applied to types uint256 and address.

Attempting to use a hexadecimal literal of length 40 as integer leads to the following compilation error:

• TypeError: Built-in binary operator / cannot be applied to types uint256 and address.

Attempting to use a hexadecimal literal of length 41 as integer leads to the following compilation errors:

• SyntaxError: This looks like an address but is not exactly 40 hex digits. It is 41 hex digits. If this is not used as an address, please prepend '00'.
• TypeError: Built-in binary operator / cannot be applied to types uint256 and address.

I assume that these errors are as part of allowing the usage of address literals without an explicit cast.
For example, allowing address x = 0x1234... instead of requiring address x = address(0x1234...).
In other words, a hexadecimal literal of length 39-41 is assumed address instead of uint256.

You should by the least fix the error message for length 39 (need to prepend '000', not '00'), and for length 41 (need to prepend '0', not '00').

It is my opinion that you should also interpret a hexadecimal literal of length 39-41 as uint256 instead of address.
Obviously, that would prevent the usage of address literals without an explicit cast, so perhaps what's needed here is a context-based decision.
For example, interpret the hexadecimal literal as a uint256 if used in a "uint" context, and as an address if used in an "address" context.

Environment

• Compiler version: 0.8.27
• Target EVM version (as per compiler settings): Paris I suppose?
• Framework/IDE (e.g. Truffle or Remix): Truffle-based Hardhat
• EVM execution environment / backend / blockchain client:
• Operating system: MacOS

Steps to Reproduce

function test(uint256 x) external pure returns (uint256) {
    uint256 a = x + 0x123456781234567812345678123456781234567;   //39 digits
    uint256 b = x + 0x1234567812345678123456781234567812345678;  //40 digits
    uint256 c = x + 0x12345678123456781234567812345678123456789; //41 digits
    return a + b + c;
}

[nikola-matic]

You should by the least fix the error message for length 39 (need to prepend '000', not '00'), and for length 41 (need to prepend '0', not '00').

This should be trivial, and something we can do pretty much immediately.

It is my opinion that you should also interpret a hexadecimal literal of length 39-41 as uint256 instead of address.
Obviously, that would prevent the usage of address literals without an explicit cast, so perhaps what's needed here is a context-based decision.

I do agree that treating hex literals as a different type depending on the number of nibbles present in said literal is also a bit crazy - but doing away with it would also be a breaking change, so it would require further discussion to come to an actual decision. Perhaps you can open this topic on the forum - I know you're active there?