Functions that contain "unnamed return variables" should trigger a compiler error and not a warning.

[StErMi]

Description

I noticed that the compiler just throws a simple warning when your contract contains a function with "unnamed return variables" and that specific function does not have an explicit return statement.

After compiling the code that you can see in the "Steps to Reproduce" section, the compiler outputs this

➜  solidity-noerror-returns git:(master) ✗ forge build
[⠢] Compiling...
[⠒] Compiling 20 files with 0.8.19
[⠰] Solc 0.8.19 finished in 1.93s
Compiler run successful (with warnings)
warning[6321]: Warning: Unnamed return variable can remain unassigned. Add an explicit return with value to all non-reverting code paths or name the variable.
 --> src/Contract.sol:8:76:
  |
8 |     function functionWithoutExplicitReturn(uint256 b) public view returns (uint256) {
  |                                                                            ^^^^^^^



warning[6321]: Warning: Unnamed return variable can remain unassigned. Add an explicit return with value to all non-reverting code paths or name the variable.
  --> src/Contract.sol:12:82:
   |
12 |     function functionWithoutExplicitReturnIfCase(uint256 b) public view returns (uint256) {
   |                                                                                  ^^^^^^^

I honestly can't think about a common use case where you define a function that must return some values, and it does not require an explicit return statement.

I think that this scenario should throw a compiler error and the developer must implement an explicit return statement to make the compilation finish successfully.

I can easily see cases where the developer forgets to add the return statement and the function just returns 0 (the default value for uint256 type). The problem is even more aggravated when the code is more complex and contains branches like in the functionWithoutExplicitReturnIfCase where this error could be missed by the developer.

I think that functions with "Unnamed return variables" should always contain explicit return statements or revert for each possible branch.

Environment

• Compiler version: 0.8.19
• Framework/IDE (e.g. Truffle or Remix): foundry
• Operating system: macOS

Steps to Reproduce

Simply run forge build

// SPDX-License-Identifier: Unlicense
pragma solidity 0.8.19;

// solhint-disable-next-line no-empty-blocks
contract Contract {
    uint256 private a = 1;

    function functionWithoutExplicitReturn(uint256 b) public view returns (uint256) {
        uint256 c = a + b;
    }

    function functionWithoutExplicitReturnIfCase(uint256 b) public view returns (uint256) {
        uint256 c = a + b;

        if (c > 10) {
            return 100;
        }
    }
}

Conclusion

Functions with "Unnamed return variables" should always contain explicit return statements or revert for each possible branch.

If not, the compiler should throw an error and force the user to fix it.

[AMIRucp]

💯

[AmitKochar1]

I agree this will be very useful. However, It does not cause any issues because we are likely to return a value in pure function, and most of the developers do read the compiler warnings. Great recommendation though.

[StErMi]

It does not cause any issues because we are likely to return a value in pure function

Could elaborate? What do you mean? Without an explicit return, the values that will be returned are the default one of the type specified in the returns keyword.

most of the developers do read the compiler warnings

In a perfect world, I would say that, but I would rather get a blocking compile error rather than deploying a smart contracts that is broken.

[nikola-matic]

The request makes sense, and we will (most likely) eventually implement this (implicit returns in general), however this would have to be shipped with a breaking release for obvious reasons. I've marked it as part of the 0.9.0 milestone, but again, given that we have higher priority issues, there's no guarantee that it will be shipped with 0.9.0; we will however go through the entire list of 0.9.0 issues and will select whatever is feasible for implementation at that moment.

Also, I might later open a general implicit returns/named variables issue and link this one (and the others like it) so we have them under the same umbrella. Just notifying in advance in case we close this issue :)