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

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \usepackage[T1]{fontenc}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
@@ skipping 596 matching lines @@
     .
 
 \end{grammar}
 
 \LMHash{}
 Functions include  function declarations (\ref{functionDeclarations}), methods (\ref{instanceMethods},  \ref{staticMethods}), getters  (\ref{getters}), setters  (\ref{setters}), constructors  (\ref{constructors}) and function literals  (\ref{functionExpressions}).
 
 \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}
 
 \LMHash{}
 A function is {\em asynchronous} if its body is marked with the \ASYNC{} or \ASYNC* modifier. Otherwise the function is {\em synchronous}. A function is a {\em generator} if its body is marked with the \SYNC* or \ASYNC* modifier.
 
 \commentary{
 Whether a function is synchronous or asynchronous is orthogonal to whether it is a generator or not. Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that {\em generates} individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, where one returns a stream. Dart also allows both synchronous and asynchronous functions that produce a single value.
 }
 
@@ skipping 3066 matching lines @@
 
 
 
 \subsection{ Function Invocation}
 \LMLabel{functionInvocation}
 
 \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$.
 If the execution completes normally or it returns without a value, the invocation evaluates to \NULL (\ref{null}).
 If the execution throws an exception object and stack trace, the invocation throws the same exception object and stack trace (\ref{evaluation}).
 
 \commentary{
 A complete function body can never break or contine (\ref{completion})
 because a \BREAK{} or \CONTINUE{} statement must always occur inside the statement that is the target of the \BREAK{} or \CONTINUE{}.
 This means that a function body can only either complete normally, throw, or return. Completing normally or returning without a value is treated the same as returning \NULL, so the result of executing a function body can always be used as the result of evaluating an expression, either by evaluating to a value or by the evaluation throwing.
 }
@@ skipping 4437 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------