Specify that a void return type doesn't cause errors in checked mode.

Specify that a void return type doesn't cause errors in checked mode.

R=eernst@google.com

Committed: https://github.com/dart-lang/sdk/commit/122345e3568e3191a7a91af2686c18d8ed40369f

[Lasse Reichstein Nielsen, 2017-05-10 13:04:23]

lrn@google.com changed reviewers:
+ eernst@google.com

[eernst, 2017-05-10 14:38:48]

LGTM

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6458: the actual return type
(\ref{actualTypeOfADeclaration}) of $f$ is not \VOID,
At this point we have assumed that (the body of) $f$ is marked \ASYNC{}, in
which case it is a static warning if the declared return type of $f$ is not a
supertype of Future<T> for some T, which would be the case if it's \VOID.

So this is a very special case exemplified by declarations like `void f(..)
async { return e; }`, incurring a static warning but still runnable. We plan to
make `return e;` in a void function a compile-time error, so this will need to
be adjusted again very soon.

Maybe add a comment like "%% TODO: Remove this line when we make `return e;` in
a void function a compile-time error."

[Lasse Reichstein Nielsen, 2017-05-11 06:10:00]

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6458: the actual return type
(\ref{actualTypeOfADeclaration}) of $f$ is not \VOID,
The change to make `return e;` an error, not just a warning, in a void function,
is something I don't expect to happen until Dart 2.0.
It's a breaking change with not real advantage in Dart 1, but in Dart 2, we will
generally make warnings into errors, so that would be the "right time" for this
change too.
I don't plan to add "TODO"s for everything we'll do in Dart 2.0, but I guess a
comment can't hurt.

It's true that a `void foo(a) async => bar(await a.baz());` would cause a
warning for now because Future<whatever bar returns> isn't assignable to `void`
(it's not a supertype requirement, just assignability). We haven't changed
assignability wrt. void, we've just changed this rule to avoid the runtime error
that can happen in well-typed programs.
Maybe it's not necessary to allow this case, I just thought it would be
consistent.

[eernst, 2017-05-11 09:56:14]

Still LGTM. ;)

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2875643002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6458: the actual return type
(\ref{actualTypeOfADeclaration}) of $f$ is not \VOID,
On 2017/05/11 06:09:59, Lasse Reichstein Nielsen wrote:
> The change to make `return e;` an error, not just a warning, in a void
function,
> is something I don't expect to happen until Dart 2.0.
> It's a breaking change with not real advantage in Dart 1, but in Dart 2, we
will
> generally make warnings into errors, so that would be the "right time" for
this
> change too.
> I don't plan to add "TODO"s for everything we'll do in Dart 2.0, but I guess a
> comment can't hurt.

I recommended the comment because I suspect that it will be non-obvious 
when adding the rule that "`return e;` is an error in a void function"
that this particular situation will no longer occur, so the line should be
deleted. I agree that we shouldn't presage all of 2.0 with TODOs, but we
might help ourselves getting it right if we note tricky corners like this
one (`void foo(a) async ..` is weird).

> It's true that a `void foo(a) async => bar(await a.baz());` would cause a
> warning for now because Future<whatever bar returns> isn't assignable to
`void`
> (it's not a supertype requirement, just assignability

Right.

> ). We haven't changed
> assignability wrt. void, we've just changed this rule to avoid the runtime
error
> that can happen in well-typed programs.
> Maybe it's not necessary to allow this case, I just thought it would be
> consistent.

I think it is consistent to let arbitrary values pass that `void` return type
test.  Weird and wrong code, of course, but we shouldn't add an exception to
the common rules to that.

[Lasse Reichstein Nielsen, 2017-05-11 12:18:31]

Description was changed from

==========
Specify that a void return type doesn't cause errors in checked mode.
==========

to

==========
Specify that a void return type doesn't cause errors in checked mode.

R=eernst@google.com

Committed:
https://github.com/dart-lang/sdk/commit/122345e3568e3191a7a91af2686c18d8ed40369f
==========

[Lasse Reichstein Nielsen, 2017-05-11 12:19:02]

Committed patchset #2 (id:20001) manually as
122345e3568e3191a7a91af2686c18d8ed40369f (presubmit successful).