Dart and analyzer behaves in the different ways when return value is not set explicitly.

[iarkh]

Dart VM version: 2.9.0-18.0.dev (dev) (Mon Jun 22 16:07:30 2020 +0200) on "windows_x64"

Here is a source code example:

main() {
  (x) {
    if (x)
      return 1;
    else
      return;
  } (true);
  print("OK");
}

Analyzer produces a compile error here.

Dart prints warning and then prints OK.

Seems like both tools should behave in the same way.

Sample output is:

$> dart test.dart
test.dart:6:7: Warning: Must explicitly return a value from a non-void function.
return;
^
OK

$> dartanalyzer
Analyzing test.dart...
error - The return value is missing after 'return'. - test.dart:6:7 - return_without_value
1 error found.

[mkustermann]

I would assume the CFE would need to issue a compile-time error if the language demands it.

/cc @johnniwinther

[johnniwinther]

@eernstg What is the state of this?

[eernstg]

We removed the rule that it is an error to have both a return; and a return e; in the same function in 9388cb3, Aug 2018. So that's not a reason for an error.

This means that we must consider inference of the signature of the function literal, and we don't have a canonicalized version of inference.md that describes the language before null-safety.

So for that case we should avoid breaking changes. The null-safety case supports an error, so I'd recommend that we also use that for the legacy case:

For the null-safety case, we have more detail on the inference:

main() {
  (x) {
    if (x)
      return 1;
    else
      return;
  } (true);
  print("OK");
}

In the example, the function literal has the empty context type, _, the 'actual returned type' UP(Null, UP(int, Never)) == int?, and inferred return type int?. This makes return; a compile-time error, because a plain return can only occur in a function with return type void, dynamic, or Null.

So I think the CFE could make it an error or keep it as a warning in the legacy case, but it must be an error in the null-safety case.