Dartanalyzer reports error message for sync* and async* functions in a strong mode

[sgrekhov]

class TestItearble<E> extends Iterable<E> {

  @override
  Iterator<E> get iterator => null;
}

TestItearble c() sync* { } // [error] Functions marked 'sync*' must have a return type assignable to 'Iterable'

main() {
  Iterable i = new TestItearble(); // Ok here
  c();
}

In a strong mode analyzer reports that "Functions marked 'sync*' must have a return type assignable to 'Iterable'". But TestItearble from above has type assignable to Iterable. Seems that there should be no error message at all.

The same issue exists for async* functions

import 'dart:async';

class TestStream<T> extends Stream<T> {

  @override
  StreamSubscription<T> listen(void onData(T event),
      {Function onError, void onDone(), bool cancelOnError}) => null;
}

TestStream c() async* { }// [error] Functions marked 'async*' must have a return type assignable to 'Stream'

main() {
  c();
}

[floitschG]

There are two parts to this bug: the error message that isn't "correct", and the question if we should even allow it.
Clearly, the sync* and async* will never return a subclass of Iterable/Stream, so the analyzer is right in telling users that this will not work.
However, I don't think that the language currently prohibits implicit downcasts in the return type for sync* and async* functions. I opened #27470 for the language.

[jmesserly]

this was an intentional strong mode bug fix. Your return type of TestStream will always fail. Offhand I don't remember the bug but I might be able to dig it up.

[jmesserly]

This was #25854.

[floitschG]

The message is wrong, though.

The given return type is assignable to Iterable.

[jmesserly]

sure, we can tweak the wording. The return type must be Iterable<T> for some T.

[floitschG]

It can also be Object.

[lrhn]

Spec is now changed to "must be a supertype of Iterable<T> for some T" (basically, must be a supertype of Iterable<⊥>).

That also allows dynamic and Object, as well as Iterable<T>, but doesn't allow any subclass of Iterable.

If it is, e.g., Iterable<int> then the yield sematnics will complain if it isn't yielding int values.

[jmesserly]

this error message could still be improved.

[srawlins]

This error is still present. ☹️