Also marked the feature specification generalized-void.md
as background material
Change-Id: I08c9b54d956208db5aa8e695540b0c1fc941e46b
Reviewed-on: https://dart-review.googlesource.com/c/86421
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We need to clarify the following case:
`dynamic foo() => print('');`,
`dynamic bar() { return print(''); }`
that is, using `return e` where `e` has type `void`, when the return
type of the enclosing function is `dynamic` (inferred or explicit).
We do not currently have any elements in the generalized-void.md
whitelist for that, so it's an error. However, invalid_returns.md
from https://dart-review.googlesource.com/c/sdk/+/60401 implies
(patchset 6: line 19-20 and 34-35) that it is allowed.
It is my impression that we agree on invalid_returns.md, and also
that it describes the current behavior (maybe not 100%?).
This indicates to me that we should, probably, add an element to
the above-mentioned whitelist to allow it.
This CL makes that change to generalized-void.md.
Change-Id: I0326081960deda907b3b4ff34bd2d60f7c9dc35b
Reviewed-on: https://dart-review.googlesource.com/64341
Reviewed-by: Erik Ernst <eernst@google.com>
As an example of a void-to-void data flow, consider `void x = foo();`,
where `foo` has return type `void`. In general, a void-to-void data
flow is a computation which is trivial (we may select one of two
branches in a conditional expression and otherwise only pass the value
on without any computation) where the expression being evaluated has
type void, and the target that receives the value is also of type
void.
This CL makes adjustments to generalized-void.md such that void-to-void
data flows are allowed.
Change-Id: Ia1722cd399c77c57cc5c61e9c10b7a84a18fe107
Reviewed-on: https://dart-review.googlesource.com/38060
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
It turns out that the special case for FutureOr<void> that I added in
https://dart-review.googlesource.com/c/sdk/+/35920 was misunderstood,
nobody really wanted it.
This CL removes all references to `FutureOr` in generalized-void.md,
which removes that special case and also the concept of types that are
"void equivalent" (because such types are not used any more).
The message here is that we are now more consistent in our protection
of developers against accidentally discarding a value which is
meaningful (just like `void foo() { return 42; }`), because they've
forgotten that the return type is `void`.
Change-Id: Ia4e6e00b2d33ff434923de7eb78d000cd7cc1c3e
Reviewed-on: https://dart-review.googlesource.com/41822
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The language team several times agreed to make it an error when a
non-void expression `e` is used in `return e;` in the body of a
function whose return type is `void`.
When `void` is changed from a near-bottom type to a top type, the
wording in the language specification (dartLangSpec.tex) does _not_
ensure that this is an error, because all types are assignable to
`void`, so we need a specific rule saying that it is an error.
This CL adds such a rule to the feature spec for generalized void.
It also adds a rule that makes it an error to have return type `void`
in a function marked `async*` or `sync*`, based on the reasoning
that they "are returning a Future/Stream/Iterable semantically",
and it would now be an error if they did that explicitly.
Change-Id: I22fed9e9fc6097bb50100a151b964045e41ef173
Reviewed-on: https://dart-review.googlesource.com/35680
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The Dart 1 specification of 'generic method syntax' had no status
indicator, it is now marked as 'background material' because generic
methods (in full) have been integrated into the language specification.
Several other changes of a similar nature.
Implication: It should now be possible for readers of these documents
to trust their status indication. As we go, we will need to update them
again, especially when something is integrated into the language
specification.
Do we want to migrate background material to another directory? Do we
want to rename the directory `informal` to `feature` or somesuch?
Change-Id: Ia3851bdbe7b5a46d71848c376906f95feb4db349
Reviewed-on: https://dart-review.googlesource.com/34663
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The informal spec of generalized void used to allow a `typeTest` on
an expression of type void. This CL removes that permission, thus
leaving only `as` as a narrow escape hatch from void, as decided at the
language team meeting on 2017-08-15.
R=lrn@google.com
Review-Url: https://codereview.chromium.org/3001063002 .
Erik Ernst