Solidity: Compiler should error on missing return statement.

Created on 26 Oct 2017  路  7Comments  路  Source: ethereum/solidity

The following code does not currently generate any errors, despite the fact that there is no return statement. The compiler should error or at least warn, when a function has an unnamed return type but does not include a return statement.

contract Apple {
    function banana() public pure returns (bool) {
    }
}
feature language design

Most helpful comment

This bug report is specifically for un-named returns. #708 is trying to address how to better deal with named returns (I'm in agreement with #708 that implicit named returns are bad).

If you are trying to have input parameters behave similarly to output parameters then I think that is a mistake. Inputs as part of an interface are very different from outputs. Inputs are the caller's side of the contract, outputs are the callee's side of the contract. Because of this, output parameters must always be provided/filled, never "unused" like input parameters.

All 7 comments

I think implicit returns should be discouraged. I'd love to see warnings for any method that has a returns value without a return statement.

Duplicate of #708

I don't believe this is a duplicate of #708. Even if #708 is implemented, this bug still needs to be fixed for non-named return values.

In that case, could you please specify the desired behaviour a little more extensively? Thanks!

Hmm, I'm not sure what else to add. If the function says it is going to return an int, but then doesn't return anything the compiler should error, like every other language out there. Just like it errors if you try to return a bool from a function that says it will return an int.

Does it make a difference if it is named or not? For example, most compilers warn if a function claims that it wants to have an int as input but then does not use it, but if the int does not have a name, there would be no warning.

This bug report is specifically for un-named returns. #708 is trying to address how to better deal with named returns (I'm in agreement with #708 that implicit named returns are bad).

If you are trying to have input parameters behave similarly to output parameters then I think that is a mistake. Inputs as part of an interface are very different from outputs. Inputs are the caller's side of the contract, outputs are the callee's side of the contract. Because of this, output parameters must always be provided/filled, never "unused" like input parameters.

Was this page helpful?
0 / 5 - 0 ratings