| 00:00 | <ljharb> | (altho really, i'd keep using [].concat if there weren't any methods that took both an iterator and a non-iterator) |
| 00:09 | <Michael Ficarra> | stage 1 concerns 😜 |
| 00:10 | <Michael Ficarra> | I'm kinda leaning toward a Iterator.of + Iterator.prototype.flat solution after doing this research |
| 00:11 | <Michael Ficarra> | that also solves the problem of TabAtkins being unhappy with our string handling (since flat would adopt flatMap's string rejection) |
| 00:12 | <TabAtkins> | So just put them all in an array and flatten it as an iterator? |
| 00:13 | <Michael Ficarra> | put them all in an iterator and flatten it |
| 00:13 | <Michael Ficarra> | Iterator.of(as, bs, cs).flat() |
| 00:14 | <Michael Ficarra> | sorry, I typo'd Iterator.of as Iterator.from since I'm so used to typing that from working on iterator helpers |
| 02:30 | <ljharb> | ooh i like that |
| 02:31 | <ljharb> | then i still get the semantics i want, but you weirdos that hate array concat's pre-symbol semantics are happy too |
| 02:46 | <bakkot> | if I understand correctly you would not get the semantics you want |
| 02:46 | <bakkot> | assuming iterator flat behaves like iterator flatMap |
| 05:12 | <ljharb> | ah, so the Iterator.of arguments would still have to be an iterator? |
| 05:13 | <ljharb> | separately, what about .join() so i don't have to make an array first? |
| 05:27 | <bakkot> | right, yes |
| 05:27 | <bakkot> | I do also want join |
| 05:27 | <bakkot> | that hopefully has less design space |