Specification: Incorrect type check rule for async return.

[eernstg]

The rules in the language specification about return statements in an async function include the following:

It is a compile-time error if $s$ is \code{\RETURN{} $e$;},
\flatten{S} is not \VOID,
and \code{Future<\flatten{S}>} is not assignable to $T$.

The context for this rule is that we are considering return e; where the static type of e is $S$ (written as S when already in math mode), in an async function $f$ with declared return type $T$. A typical example would be the following:

Future<num> f() async {
  return Future<int>.value(42);
}

This is allowed, because $S$ as well as \code{Future<\flatten{S}>} is Future<int>, and $T$ is Future<num>. Similarly, return 42 is allowed because \code{Future<\flatten{S}>} is again Future<int>.

However, the following should be allowed, but is currently specified to be a compile-time error:

Future<Future<int>> g() async {
  return Future<int>.value(42);
}

Here, \code{Future<\flatten{S}>} is Future<int> and $T$ is Future<Future<int>>, and the former is not assignable to the latter.

So we must change this rule.

Note that the vm and dart2js already run the following code with no issues:

import 'dart:async';

Future<Future<int>> g() async {
  return Future<int>.value(42);
}

void main() async {
  print(await await g()); // Prints '42'.
}

The analyzer currently rejects this program, but it is a non-breaking change to allow it. Also, the analyzer reports the following:

Analyzing n026.dart...
  error • A value of type 'int' can't be returned from function 'g' because it has a return type of 'Future<int>'. • n026.dart:4:10 • return_of_invalid_type
1 error found.

which is wrong with respect to the type of the returned expression as well as the declared return type, so there would be a need to take a look at the relevant code for this check in any case.

[ili]

5 cents, if you allow: it would be better to deny using async without await, because this causes missunderstood about how does it works.

[eernstg]

Hello @ili! There's nothing that prevents writing an async function that does not contain any asynchrony:

Future<int> foo() async => 1;

So what would it mean to deny using async without await in that situation?

[Edit] I think I know what you mean now: When an await is needed in order to perform a return in an async function, it must be written explicitly. That would indeed be simpler, but it is also seriously breaking. You could say, conversely, that if we hadn't had these implicit await operations, it would be a very typical convenience feature that we might add to the language. ;-)

In this particular case the main issue is that the specification needs to be fixed for correctness. It does connect to #914 as well, because it prepares the spec for not causing a breaking change by accident when we change the assignability rules along with the introduction of null-safety.

[leafpetersen]

So we must change this rule.

I'm not sure about must - there's nothing wrong with the rule. I'm happy to consider changing it though. Is this just a sub-issue for your revisit of the return rules?

[eernstg]

I don't understand why you do not think that the following is a bug in the specification:

The following should be allowed, but is currently specified to be a compile-time error:

Future<Future<int>> g() async {
  return Future<int>.value(42);
}

Here, \code{Future<\flatten{S}>} is Future<int> and $T$ is Future<Future<int>>, > and the former is not assignable to the latter.

As I see it, it is obviously a spec bug when it is a compile-time error to return an expression of type U in an async function with return type Future<U>.

[eernstg]

Closing: #941 and #948 landed corrections for this in the null-safety specification.