With dart, dartanalyzer, and dart2js from commit 0a7dcf17eb5f2450480527d6ad1e201fb47f1e36, we get the following error (with slightly different formatting):
Error: Functions marked 'sync*' must have a return type assignable to 'Iterable'
But Foo<T> is assignable to Iterable<T> for all T (and thus also Iterable<dynamic>, if that's the meaning of assignable to 'Iterable'), so the error message has an implication which is just not true.
Of course, the actual Iterable which is returned is provided by the platform, so any attempt to specify a return type such that Iterable<T> is a proper superinterface will cause a dynamic failure, so the program "won't work" anyway.
A similar thing occurs when the function is async*, with Stream.
We could change the language specification to say that these return types must be supertypes of Iterable<Null> resp. Stream<Null>, and then change the error messages from all tools accordingly.
@lrhn, @leafpetersen, do you see any reason why we would not change the language specification in this manner?
(If we take this course then we can change this issue to be a meta-issue for tool changes later on; for now I'll mark it as area-specification).
Consider the following program:
With
dart
,dartanalyzer
, anddart2js
from commit 0a7dcf17eb5f2450480527d6ad1e201fb47f1e36, we get the following error (with slightly different formatting):But
Foo<T>
is assignable toIterable<T>
for allT
(and thus alsoIterable<dynamic>
, if that's the meaning ofassignable to 'Iterable'
), so the error message has an implication which is just not true.Of course, the actual
Iterable
which is returned is provided by the platform, so any attempt to specify a return type such thatIterable<T>
is a proper superinterface will cause a dynamic failure, so the program "won't work" anyway.A similar thing occurs when the function is
async*
, withStream
.We could change the language specification to say that these return types must be supertypes of
Iterable<Null>
resp.Stream<Null>
, and then change the error messages from all tools accordingly.@lrhn, @leafpetersen, do you see any reason why we would not change the language specification in this manner?
(If we take this course then we can change this issue to be a meta-issue for tool changes later on; for now I'll mark it as area-specification).