| 13:34 | <HE Shi-Jun> | I think Java Streams is ok, but we should note it is intentionally named as "Stream", to make it clear it's not Iterable/Iterator. If we follow Java design, we should also consider change iterator helpers to "Stream". Actually I think Emitter proposal is a very similar and more powerful Stream-like API, a good alternative to iterator helpers. |
| 13:55 | <HE Shi-Jun> | bakkot: And the original question is whether number range() should be iterable/iterator, this is a separate question, not direct relate to the design choice of iterator helpers or iterable helpers or stream... Generally speaking I prefer iterable. I'm ok with iterator/stream version if it is make clear that's a iterator/stream (eg. naming it as Iterator.integers() or Java-like IntStream.range()). See https://github.com/tc39/proposal-Number.range/issues/57 |
| 17:19 | <bakkot> | Java's Streams happened after they'd already defined their Iterator interface and could no longer redefine it as a class; I don't think the naming there is that informative |
| 17:19 | <bakkot> | other languages like Scala and Rust did not make that choice |
| 17:20 | <bakkot> | anyway I agree with you about the particular question of Number.range, I'm mostly objecting to the assertion that every language which has an equivalent of iterator helpers has them for iterables rather than iterators |
| 18:08 | <HE Shi-Jun> | Java's Streams happened after they'd already defined their |
| 19:05 | <bakkot> | Oh, yeah, ok |
| 19:05 | <bakkot> | Yeah I dunno |
| 19:08 | <bakkot> | possibly it's because java iterators support .remove and such |
| 21:54 | <jschoi> | bakkot, Michael Ficarra, nicolo-ribaudo: Can you check whether this Gist (about Array.fromAsync and AsyncIterator.prototype.toArray) matches your understanding? https://gist.github.com/js-choi/5b49b350995c5a44571be3d314e38162 (I plan to post it in proposal-array-from-async#19 and refer to it from proposal-iterator-helpers#168.) |
| 22:12 | <bakkot> | jschoi: lgtm |
| 22:12 | <bakkot> | though this line is a bit weird:
|
| 22:12 | <bakkot> | I don't know what "identity function" means there |
| 22:12 | <jschoi> | Yeah, I just revised it. Refresh the page? |
| 22:12 | <bakkot> | ah, sure |
| 22:13 | <bakkot> | I would change the “identity function” of Array.fromAsync to the “default mapping function” of Array.fromAsync |
| 22:13 | <jschoi> | Will do. Thanks for checking! |
| 22:13 | <bakkot> | or something like that. "identity function" is a property of values, not of functions like "fromAsync" |
| 22:13 | <jschoi> | Hopefully now we will have all our ducks in a row with regards to consistency between Array.fromAsync, iterator-helpers, and for await. |
| 22:16 | <bakkot> | I believe so! |
| 22:16 | <bakkot> | I have an agenda item about similarly lining up yield* in async generators (https://github.com/tc39/ecma262/pull/2819) |
| 22:16 | <bakkot> | working on slides for it now |