Solidity: Support overload of named calls

[rainbreak]

Solidity should support overloading functions with named arguments. I'm not sure if the inability to do this at present is intentional or not.

This should be allowed:

contract Demo {
    function f(uint x) {
    }
    function f(uint x, uint y) {
    }
    function call() {
        f({x: 1, y: 2});
    }
}

However, it currently fails (solc v0.3.4):

demo.sol:7:9: Error: Unable to determine overloaded type.
        f({x: 1, y: 2});
        ^

[VoR0220]

use case? Seems kind of like a hassle...

[redsquirrel]

Overloaded methods is a common pattern in programming languages.

On Tuesday, June 7, 2016, RJ [email protected] wrote:

use case? Seems kind of like a hassle...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/solidity/issues/637#issuecomment-224396226,
or mute the thread
https://github.com/notifications/unsubscribe/AAAJ0L6ouGjnU32H24FrQkh44vdA-G2Qks5qJc3BgaJpZM4IwHVS
.

[VoR0220]

yes...overloaded methods via the types...but not the names of the args. Idk. I'm not seeing the use case here.

[redsquirrel]

Oh. Right. Sorry I missed that! 👍🏼

On Tuesday, June 7, 2016, RJ [email protected] wrote:

yes...overloaded methods via the types...but not the names of the args.
Idk. I'm not seeing the use case here.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/solidity/issues/637#issuecomment-224397647,
or mute the thread
https://github.com/notifications/unsubscribe/AAAJ0MwfuZaaNAO9uqEpoZ5Zb8cYjgeRks5qJc8JgaJpZM4IwHVS
.

[rainbreak]

I was using named args to make my code easier to read (method with 9 args). I found that I needed to overload the method and was surprised that I was no longer allowed to use named args.

It seems inconsistent to have both overloading and named args, but not allow both together. The use case is anywhere that you would think named args were appropriate.

I don't know the story in other languages. Might be this is an odd request, but it seems intuitive to me.

[chriseth]

Yes, this is a "TODO" in the code. Should not be very hard to accomplish.

[rainbreak]

@chriseth: can you point to the TODO in the code so this is easier to pick up?

[seusher]

@chriseth - I didn't see a TODO in the code, but the issue seems to be that in TypeChecker.cpp the TypeChecker::visit(FunctionCall const& _functionCall) method does a few checks to skip adding the argument types to the function call (based on isPositionalCall), and when that eventually gets passed to TypeChecker::visit(Identifier const& _identifier) it first checks whether the argument types are annotated, and if not, it assumes it should look up a variable declared at a higher scope, which of course, is the wrong thing to do.

Any idea why types are only annotated when using positional parameters?

I had edited this comment since I broke my test while changing parameter names, but I fixed it. To test whether skipping annotation for positional parameters mattered, I commented out the if conditions that cause type annotation to be skipped when using named parameters. this resulted in type annotations being added even when calling a function with positional parameters. With this change, all existing non-ipc tests succeeded (I can't run ipc tests yet).

I also wrote my own test, which also passes:

BOOST_AUTO_TEST_CASE(overload_function_call_with_names_in_named_args)
{
    char const* sourceCode = R"(
    contract test {
        function fun(uint a, uint b) returns (uint r) {
            r = a + b;
        }

        function fun(uint c) returns (uint d) {
            d = c;
        }

        function funfinal() returns (uint e) {
            e = fun({c: 1});
        }
    }
    )";
    CHECK_SUCCESS(sourceCode);
}