Adjusted generalized-void.md to make for-in on a void iterator an error, except when the iteration variable has type void.

A similar rule applies to asynchronous for-in loops.

Change-Id: I88ba234c27a38167eaac0350d269e88894a0fe9e
Reviewed-on: https://dart-review.googlesource.com/35920
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This commit is contained in:
Erik Ernst
2018-02-14 18:44:03 +00:00
committed by commit-bot@chromium.org
parent ae5534a394
commit c01d59bc7e
@@ -312,6 +312,22 @@ marked `async*`, or `sync*` has return type `void`.
"fire-and-forget" operation, that is, it is not even useful for the caller
to synchronize with the completion of that task.*
It is a static warning (Dart 2: a compile-time error) for a for-in
statement to have an iterator expression of type `T` such that
`Iterator<void>` is the most specific instantiation of `Iterator` that is a
superinterface of `T`, unless the iteration variable has type void.
It is a static warning (Dart 2: a compile-time error) for an asynchronous
for-in statement to have a stream expression of type `T` such that
`Stream<void>` is the most specific instantiation of `Stream` that is a
superinterface of `T`, unless the iteration variable has type void.
*Hence, `for (Object x in <void>[]) {}` and
`await for (int x in new Stream<void>.empty()) {}` are errors, whereas
`for (void x in <void>[]) {...}` and `for (var x in <void>[]) {...}` are OK. The
usage of `x` in the loop body is constrained, though, because it has type
void.*
During bounds checking, it is possible that a bound of a formal type
parameter of a generic class or function is statically known to be the type
void. In this case, the bound is considered to be the built-in class