Try to make returning void within dynamic an error

[MichaelRFairhurst]

Work to do:

• investigate if plausible to land via internal code changes
• land updates internally
• land (and ship) updates externally
• land external updates internally
• enable in analyzer

Split out from #30177

[bwilkerson]

@MichaelRFairhurst How is work on this issue going?

[MichaelRFairhurst]

fixes are all landed, but @leafpetersen decided it might not be best for Dart to land this in the analyzer.

@leafpetersen is that decided for sure yet? Can we close this?

[eernstg]

The language team has agreed to make one change that would be quite important for this issue: An => function which has return type void and an => function whose returned expression has type void are syntactic sugar for an expansion that does not return anything (so we get the null return value from reaching the end of the function):

void foo() => 42; // Sugar for `void foo() { 42; }`.
foo() => print('Hello!'); // Sugar for `void foo() { print('Hello!'); }`.

I suspect that this decision is sitting in the pipeline (so you might not have had a chance to hear about it yet, and it isn't in any feature spec), but it should change the situation around a substantial number of functions which are "void with =>". The remaining ones (stuff like foo() { ... return print(''); }) would remain an error, so those fixes would still be needed.

I believe that almost all the other fixes (presumably they would be "add an explicit void return type to an => function") would be perfectly fine, though, because they could be claimed to be more readable than the ones that rely on this new way to get a void return type. So I believe there's no need to remove any of the fixes, no matter what.

Of course, the semantics of the targeted => functions changes and all compilers must be changed accordingly, but for the analyzer I guess it might be a relatively small change (it just needs to consider those functions to have return type void).

[MichaelRFairhurst]

foo() => print('Hello!'); // Sugar for `void foo() { print('Hello!'); }`.

Is this for top levels or just local closures?

[eernstg]

Obviously, we need to specify this, like right now. However, let me try to give an estimated answer. ;-)

In all cases, it's about => functions and only about => functions.

The discussion was specifically about top-level functions, so the rule would apply for them.

For static functions, we might want to consider class members together, in order to keep the number of rules/exceptions low. In isolation, it seems likely that static functions should be able to use this rule, just like top-level functions.

For instance methods there is a clash between omitting parts of the method signature and getting them implicitly from a supertype, and applying this rule when the return type is omitted. So considering void foo() => 42; as an instance method declaration to mean void foo() { 42; } would make sense, but considering bar() => print("Hello!"); to mean void bar() { print("Hello!"); } is problematic, in particular if you would otherwise have "inherited" some T as the return type, and the fact that the "returned expression" is of type void was a mistake. In that case it makes more sense to say "print("Hello!") is not assignable to T" than it does to say "Invalid override of return type T with return type void".

For local functions there is no ambiguity: They already get an inferred return type if the return type is omitted. The reason why this is possible is that they have no dependency cycles, so the complexity cannot explode.

Function literals have inference, too.

So we need to carefully consider the locations where this rule is applied, starting with the safe bet which is the top level.

[MichaelRFairhurst]

Closing, we can have a new ticket made once the change is specced, and that may be after the front end/analyzer integration anyways. Sound good @eernstg ?

[eernstg]

Sounds good @MichaelRFairhurst, thanks!

Specification work is handled via #33069.