Should JS iterators implement Dart Iterable?

[vsmenon]

From @jmesserly on June 25, 2015 23:26

This seems like it would be useful in general. The downside is that something could have [Symbol.iterator]() but already define some of the same method names as Dart's Iterable, so we'd have to decide which one wins (at least, for dynamic dispatch).

Without this, we won't have very good interop with JS generators, so IMO it's worth it. It would also simplify sync* (#221), so Dart generators just get Iterable "for free". Otherwise we'll have to wrap the ES6 generator.

Exposing explicit conversion APIs would be the other way to go here.

See also #245, a similar issue with Future/Promise.

Copied from original issue: dart-archive/dev_compiler#247

[vsmenon]

From @jmesserly on July 17, 2015 20:0

one complication can be seen in

sdk/tests/language/syncstar_yield_test.dart

Line 47 in d37ac8d

// TODO(sigurdm): Check up on the spec here.

Unlike ES6 generators, Dart sync* functions seem to capture parameters differently. Even though the generator function is only called once, each iterator gets a fresh copy of the parameter. It's not clear to me that this is actually specified one way or the other, but for now I'm going to try and match the other implementations.

edit: it's still useful to make interop better, so this bug is worth fixing. but I'm not sure sync* function bodies can actually be function* in JS, unless the parameters aren't mutated (which is probably common, and we already look for that in other cases and use it to generate better code).