Make void-arrow-functions statically accept any expression type.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 7933e942574ee7caec78f006edbeae3bc3e37d7f..ce1f51f8d90fa7f5fbf13ce538cf37b766f386dc 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -614,14 +614,22 @@ Functions include  function declarations (\ref{functionDeclarations}), methods (
 \LMHash{}
 All functions have a signature and a body. The signature describes the formal parameters of the function, and possibly its name and return type.  A function body is either:
 \begin{itemize}
-\item A block statement  (\ref{blocks}) containing the statements  (\ref{statements}) executed by the function, optionally marked with one of the modifiers: \ASYNC, \ASYNC* or \SYNC*. In this case, if the last statement of a function is not a return statement (\ref{return}), the statement \code{\RETURN{};} is implicitly appended to the function body.
+\item A block statement (\ref{blocks}) containing the statements  (\ref{statements}) executed by the function, optionally marked with one of the modifiers: \ASYNC, \ASYNC* or \SYNC*.

[eernst, 2017/05/19 09:48:14]

Might as well fix all the stray double spaces (there's one at
`(\ref{statements})`).

I was surprised that the last sentence was moved from normative text to
commentary, but I can see that it is the right thing to do. Checking for
evidence elsewhere that a function body execution that falls through at the end
will return \NULL{}: 

Found \section{Return} saying `Executing .. return; .. returns with no value.`
and 

`Otherwise, if the execution completes normally or returns with no value, then
$e$ evaluates to \NULL.`

in \subsubsection{New} (about factory constructor execution), and

`If the execution completes normally or it returns without a value, the
invocation evaluates to \NULL (\ref{null}).`

in \subsection{Function Invocation}. Voila!

[Lasse Reichstein Nielsen, 2017/05/22 14:18:49]

Indeed, I wrote that into the specification of method termination because then
this line wouldn't be necessary.

I had a problem with this line: In a void function, it should give a warning to
have a `return null;` statement. It doesn't, arguably because the "added" return
statement is synthetic, but it's not really specified anywhere, and it's easier
if it just isn't there.

[eernst, 2017/05/22 16:06:40]

Acknowledged.

 
-\rationale{
-Because Dart is optionally typed, we cannot guarantee that a function that does not return a value will not be used in the context of an expression. Therefore, every function must return a value. A \RETURN{} without an expression returns \NULL{}. For generator functions, the situation is more subtle. See further discussion in section \ref{return}.
+\commentary{

[eernst, 2017/05/19 09:48:14]

We haven't been re-categorizing rationale/commentary very much, but this looks
to me like a rationale: _Why_ must every function return a value? Then the
normative part should explain _that_ it does so, but we know that now. So why
not just keep it at `\rationale{}`?

[Lasse Reichstein Nielsen, 2017/05/22 14:18:49]

My reason for changing this is that this is really the rationale for adding
"return null;" - which the previous paragraph doesn't do any more. So, it's
"rationalizing" something that we haven't said, which is just confusing. That is
We didn't say *that* every function must return a value, so why is there
rationale saying *why*?

so I made it a comment. It is just reiterating rules from elsewhere to give the
reader a helpful reminder about how things work, which is comment-ish.

[eernst, 2017/05/22 16:06:40]

Acknowledged.

+Because Dart is optionally typed, we cannot guarantee that a function that does not return a value will not be used in the context of an expression. Therefore, every function must return a value. A function body that ends without doing a throw or return will cause the function to return \NULL{}, as will a \RETURN{} without an expression. For generator functions, the situation is more subtle. See further discussion in section \ref{return}.
 }
 
 OR
-\item of the form   \code{=> $e$} which is equivalent to a body of the form \code{\{\RETURN{} $e$;\}} or the form \code{\ASYNC{} => $e$} which is equivalent to a body of the form \code{\ASYNC{} \{\RETURN{} $e$;\}}. \rationale{The other modifiers do not apply here, because they apply only to generators, discussed below, and generators do not allow the form \code{\RETURN{} $e$}; values are added to the generated stream or iterable using \YIELD{} instead.}
+\item of the form \code{async => $e$} or the form \code{\ASYNC{} => $e$}, which both return the value of the expression $e$ as if by a \code{return $e$}. \rationale{The other modifiers do not apply here, because they apply only to generators, discussed below, and generators do not allow returning a value, values are added to the generated stream or iterable using \YIELD{} instead.}

[eernst, 2017/05/19 09:48:14]

I believe it's a typo to have `async` in the first code snippet.

In this particular case, however, I actually think that the non-normative text
should be a `\commentary{}`: It explains why the normative text doesn't mention
\ASYNC* and \SYNC*, based on the rules of the language, but it does not give a
rationale for a language design decision.

[Lasse Reichstein Nielsen, 2017/05/22 14:18:49]

Yes on typo. Fixed.

Changed to commentary.

I'm not sure what the original distinction between commentary and rationale was,
but this rational is explaining a "why" (why only those two forms), which might
have been the reasoning.

Changed "not allowed returning" to "not allowed to return" because I can
actually read that.

[eernst, 2017/05/22 16:06:40]

Acknowledged.

+}
+Let $R$ be the static type of $e$
+and let $T$ be the actual return type (\ref{actualTypeOfADeclaration})
+of the function that has this body.
+It is a static warning if $T$ is not \VOID{} and either
+the function is synchronous and the static type of $R$ is not assignable to $T$,
+or the function is asynchronous and \code{Future<flatten{$R$}>}

[eernst, 2017/05/19 09:48:14]

`\code{Future<$flatten$($R$)>}`, for consistency with other occurrences of
"flatten".

There is one more occurrence of "flatten" in non-math-mode which can be found
with `It is a static type warning if the body of \$f\$ is marked \\ASYNC\{\}`,
in \subsection{Return}. We may again choose to fix this now that we noticed it.

It's a nice coincidence that we've eliminated the syntactic sugar approach and
then (1) we need to give the typing rules here because we don't get them by
desugaring, and (2) we needed special casing anyway. ;-)

[Lasse Reichstein Nielsen, 2017/05/22 14:18:49]

Flatten fixed, both three places. The other ones could also be found by
searching for "flatten(" :)

We should have a macro for flatten. I think I have one in another CL.

It's not a surprising coincidence - I made this change *because* I needed a
place to write the special-case for void, so it couldn't use the original
rewrite any more - since there was no way to distinguish an arrow-void-function
from a block-void-function at the return statement.

[eernst, 2017/05/22 16:06:40]

Oops, there's still one typo: '{..}' should be changed to '(..)'.

+is not assignable to $T$.
 
 \end{itemize}
 
@@ -3707,6 +3715,10 @@ As discussed in section \ref{errorsAndWarnings}, the handling of a suspended iso
 \LMHash{}
 Function invocation occurs in the following cases: when a function expression  (\ref{functionExpressions}) is invoked (\ref{functionExpressionInvocation}), when a method (\ref{methodInvocation}), getter (\ref{topLevelGetterInvocation}, \ref{propertyExtraction}) or setter (\ref{assignment}) is invoked or when a constructor is invoked (either via instance creation (\ref{instanceCreation}), constructor redirection (\ref{redirectingConstructors}) or super initialization). The various kinds of function invocation differ as to how the function to be invoked, $f$,  is determined, as well as whether \THIS{} (\ref{this}) is bound. Once $f$ has been determined, the formal parameters of $f$ are bound to corresponding actual arguments. When the body of $f$ is executed it will be executed with the aforementioned bindings.
 
+\LMHash{}
+Executing a body of the form \code{=> $e$} is equivalent to executing a body of the form \code{\{ return $e$; \}}.
+Execution a body of the form \code{async => $e$} is equivalent to executing a body of the form \code{async \{ return $e$; \}}.

[eernst, 2017/05/19 09:48:14]

I think we should use `\ASYNC{}` to get the right font in code.

There is one occurrence of `async` in text. You can find it by a search for `and
the result of an async function will never have type`. If you don't think it's
too messy, we could fix that also in this CL, and then always use `\ASYNC{}` and
`\ASYNC*` whenever we refer to that concept.

+
 \LMHash{}
 If $f$ is synchronous and is not a generator (\ref{functions}) then execution of the body of $f$ begins immediately.
 If the execution of the body of $f$ returns a value, $v$, (\ref{completion}), the invocation evaluates to $v$.