Consider removing "named returns"

[ethers]

Related to #719, #973, #708. Grouping the examples here.

These behaviours can be confusing for people who are starting out with the language. Solidity has been criticized as a language that hasn't been designed with safety in mind, and this is one feature where safety was overlooked imo.

contract Example {
    uint n = 2;

    function test() constant returns (uint n) {
        return n; // Will return 0
    }
}

And another:

contract Example {
    uint n = 2;

    function test() constant returns (uint n) {
        n = 1;
        return n; // Will return 1
    }
}

One more:

contract Example {
    uint n = 2;
    uint x = 3;

    function test() constant returns (uint x) {
        uint n = 4;
        return n+x; // Will return 4
    }
}

A case where the explicit return statement is "overshadowed" by the named return.

function foo() returns (uint r) {
    r = 1;
    if (somethingComplexThatReturnsFalse()) {
        return 2;
    }
}

Instead of somethingComplexThatReturnsFalse imagine a bunch of other code and loops.

[ethernomad]

I've always really liked the named returns feature of Solidity. If anything return should be changed to not be able to take a value.

[redsquirrel]

I would love to see us drop named returns altogether. I think it improves code readability to be explicit about returns.

[chriseth]

We already have #973 (comment) for the first three examples. I think named returns in general are a great idea for readability - it will tell the user the meaning of the return value.

• If you are talking about being able to assign to the return value, this is a different topic.
• If you are talking about being able to use a non-explicit return in a function returning a value, it is also a different topic.

[ethers]

For readability, can the meaning of the return value be expressed as a code comment?

"being able to assign to the return value" is that this example?

function foo() returns (uint r) {
    r = 1;
    if (somethingComplexThatReturnsFalse()) {
        return 2;
    }
}

Or is the example a case of "non-explicit return in a function returning a value"?

Here's another "bad" one (0 will be returned):

function foo() returns (uint r) {
    if (somethingComplexThatReturnsTrue()) {
        return;
    }
    r = 1;
}

[ethers]

The "named" returns feature is another quirky one that gets burdened on Solidity writers and reviewers to get correct.

contract C {
    address[] public authorities;

    function foo() constant returns(uint count) {
        count = 2;
        return authorities.length;  // "Overrides" the "named" return. returns 0, the default for all EVM values
    }

}

contract C {
    address[] public authorities;

    function foo() constant returns(uint count) {
       return;  // return 0. It can appear that the default value (of 0) is returned.
    }

}

contract C {
    address[] public authorities;

    function foo() constant returns(uint count) {
        count = 2;
        return;  // returns 2. Here return doesn't return the default value (of 0) but acts like a "break".
    }

}

[github-actions]

Hi everyone! This issue has been 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.