Adjust the initial actual returned type to avoid spurious `Null`

[eernstg]

Thanks to @sgrekhov for bringing up this topic. Consider the following program:

var f1 = () sync* {
  return;
};

var f2 = () sync* {};

The specification in this section implies that the function literal that contains return; has a return type of Iterable<Never>. This makes sense because the returned iterable is empty, which means that it is safe to claim that every returned object has whichever type you want.

The reason why the return is Iterable<Never> rather than Iterable<Null> is that PR #4210 disabled the action taken when a return; is encountered: With that PR, the actual returned type is not updated to include Null when the function is a generator. This is working correctly because return; in a sync* body doesn't actually add a null to the returned iterable. Similarly for async* generators and Stream.

However, the rules imply that the second function literal — the one that does not contain a return; statement — has a return type of Iterable<Null> for sync* and Stream<Null> for async*.

The culprit is that the initial value of the 'actual returned value' is chosen to be Null in the case where the end of the function body is reachable. This is suboptimal in the case of generators for the same reason as the one in #4210. Hence, we should change the relevant sentence as follows. This is the wording that we currently have:

The actual returned type of a function literal with a block body is computed as follows. Let T be Never ...

We can change it as follows:

The actual returned type of a function literal with a block body is computed as follows. If the function literal is a generator then let T be Never. Otherwise, let T be Never ...

@dart-lang/language-team, WDYT? Does it need breaking change processing, or can we just go ahead and fix it?

[lrhn]

Agree. And why I think it's dangerous to reuse spec concepts across significantly different areas.
Yielded values are not returned values, and nothing except yields should have any effect on the return type of a generator. That reaching the end of the generator function has any effect at all is a sign that the algorithm is mixing concepts.

The actual returned type of a function literal with a block body is computed as follows. If the function literal is a generator then let T be Never. Otherwise, let T be Never ...

So it's just always Never

Rather than a minimal charge, I'd prefer to completely separate the algorithms for generators from those for non-generators. And for those, maybe handle async functions by themselves too. The semantics of return in an async function is one of the trickiest in the spec.

Trying to do all four kind of functions in one algorithm with different cases is just making things harder.

[eernstg]

So it's just always Never

No, it's always Never for generators, but non-generators still have the two cases which were previously used with all functions (it says 'Let T be Never [in one case]. Let T be Null [in another case].' after the new sentence about generators). But it's certainly possible that the exact wording can be made clearer.