dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.21k stars 1.57k forks source link

Should JS iterators implement Dart Iterable? #28320

Open vsmenon opened 7 years ago

vsmenon commented 7 years ago

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-lang/devcompiler#247

vsmenon commented 7 years ago

From @jmesserly on July 17, 2015 20:0

one complication can be seen in https://github.com/dart-lang/sdk/blob/d37ac8d4d0774dc72235e484c65164689d1503ba/tests/language/syncstar_yield_test.dart#L47

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).