Interface implementations should have the same parameter names as the interface

Language Design
1

Hello everyone! this is my first time posting to this community, so please
excuse me if I get any part of the netiquette wrong.

Recently I’ve been working on a linter
rule to
disallow use of positional arguments when a function has more than a few
parameters, requiring usage of named parameters instead.

However, I realized that currently Solidity doesn’t consider the parameter names
part of the interface definition (which of course makes sense from an ABI point
of view), but it can be confusing when using named parameters to invoke
functions. Let me illustrate:

given an interface

interface IFoo {
    function foo(uint256 a, uint256 b) external returns (uint256);
}

it should not be a valid override to use different names for the parameters.

Valid:

contract Foo is IFoo {
    function foo(uint256 a, uint256 b) external returns (uint256);
}

Currently valid, proposed invalid:

contract Foo is IFoo {
    function foo(uint256 other, uint256 name) external returns (uint256);
}

Allowing the latter causes confusion when using named parameters to invoke
functions, since types implementing the same interface would have different ways
of invoking the same function

I created a small repo with an example of this behaviour:

What do you think?

2

I think this is something that might make sense being enforced by a linter, but not necessarily by the compiler.

It’s a bit too opinionated and I’d expect there to be many people who just don’t care. The fact that argument names are not a part of function signature and therefore do not matter in inheritance is pretty well established practice in C-like languages.

Some people might even actively dislike it because it would disallow even trivial adjustments, like for example changing the original name to match your coding style (e.g. aValue → a_value). Or sometimes replacing a cryptic name chosen by the library with something more readable. Or changing a generic name to something that better matches how the function interprets it.

On top of that it’s a breaking change, which would be annoying if you’re doing it all over your code base. Having linter do that would allow people who do want it to have it without others being forced to.

2 Likes
3

How about sharing your findings on the Solidity GitHub repository to gather feedback