Disallow function signatures that have same name and same implicitly convertable arguments

[hrkrshnn]

Was bought up in solidity gitter

library Lib {
    function foo(bytes32) internal pure returns (bytes32) {}
    function foo(bytes4) internal pure returns (bytes32) {}
}

Compiles correctly,

However

bytes4 b = 0x01020304;    
Lib.foo(b);

returns

Error: Member "foo" not unique after argument-dependent lookup in type(library Lib).
  --> <stdin>:10:10:
   |
10 | 		return Lib.foo(b);
   | 		       ^^^^^^^

I think because bytes4 can be implicitly converted to bytes32 making the resolution not unique.

On the other hand, it's probably impossible to make an internal call to function foo(bytes4). External calls have to be made by manually using .call and manual encoding.

---

I think we should have an error during checkDuplicateFunctions if two functions have the same name and their arguments can be implicitly converted to each other.

[chriseth]

Related to https://github.com/ethereum/solidity/issues/1256

[hrkrshnn]

The issue https://github.com/ethereum/solidity/issues/1256 proposes that the conversion should be allowed.

My arguments for disallowing it would be:

1. Calling such functions from the frontend becomes more complicated. For example, if there is f(uint) and f(uint128), calling either of them from the front-end is not as straightforward as contract.f(10). Even though frontends seem to have support for calling them ether.js: overloaded functions and web3.py: invoke ambigous functions
2. Allowing it would mean adding more rules to reference resolution.

On the other hand, we have the following issues if this is disallowed:

1. Unable to write interfaces to contracts that have already implemented this. Both existing solidity contracts, and contracts from other languages.
2. Perhaps this would affect templated functions. Say for templated function f<T>(T val), this might mean that f<uint> and f<uint128> cannot coexist.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.