Add compiler option for warn on implicit return statement.

[MicahZoltu]

function fruit() returns (bytes32 fruitName) {
  fruitName = "apple";
}

This function does not result in an error or warning because an implicit return statement is added to the end of the function that returns whatever is in the fruitName local variable. In a large codebase this can lead to subtle bugs due to the implicit nature of the return statement. I would like the ability to set a compiler flag that allows me to make this a warning. Alternatively, making it always be a compiler warning is fine by me as I think it is not a good practice to have implicit return values.

[MicahZoltu]

Note: I want to use the named return values because they get included in the ABI that the compiler generates which makes interacting with the contracts from external sources notably easier in some cases and it provides a certain amount of self-documentation.

[chriseth]

Do I understand you correctly that this is about a warning if there is a code path that reaches the end of a function (which returns something) without an explicit return statement?

[chriseth]

Perhaps we could have something like

function fruit() returns implicitly (bytes32 fruitName) {
  fruitName = "apple";
}

[redsquirrel]

Instead of adding implicitly to the language, why not deprecate implicit returns?

[chriseth]

@redsquirrel hm, perhaps I'm the only one who really likes them?

[roadriverrail]

@chriseth I can't say I'm a fan of implicit returns, especially where readability and security matter. That said, I think it's quite possible to offer this as a pragma and not super hard to write. I seem to remember playing around with the "unnamed return variable" when I was doing unused variable warnings.

…

On Fri, Sep 22, 2017 at 8:54 AM chriseth ***@***.***> wrote: @redsquirrel <https://github.com/redsquirrel> hm, perhaps I'm the only one who really likes them? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2951 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlhYPZtckrkgR8pPPy2x6gLM-9gFl7Yks5sk63zgaJpZM4PgEGS> .

[redsquirrel]

especially where readability and security matter

See also: smart contracts 😉

[MicahZoltu]

I'm okay with returns implicitly or a pragma. In a perfect world, explicit would be the default and pragma/compiler options/keyword would be available if you wanted your compiler to be more lenient. In general my philosophy is that compilers should be ultra strict by default with options to be less strict rather than the other way around.

However, I will take anything I can get, and if that means the default is current behavior and I have to add a pragma or do returns explicitly (bytes32 fruitName) I can accept that and be happy.

[chriseth]

@MicahZoltu oh of course explicit returns would be the default, otherwise the keyword would be returns explicitly.

[github-actions]

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]

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.