TC39 General
2023-01-25
plaintext logs
prev next
source on github
02:39
<sirisian>
Was thinking more about async stuff. https://pastebin.com/mtMypZC9 I've never needed async getter/setters, but introducing a ~= operator could make the setter part feasible for equality and destructuring potentially.
22:37
<Justin Ridgewell>
bakkot: Is there an issue or chat for parallel async iterators?
22:44
<Justin Ridgewell>
We've had similar discussion before: https://matrixlogs.bakkot.com/TC39_General/2022-04-19#L47-L71
22:45
<Justin Ridgewell>
I guess it'd be ok if the iterator allowed parallel computation, as long as it wasn't exposed to the consumer doing for await (const item of it)
22:46
<Justin Ridgewell>
But, it's not really going to help much, because your "parallel" 2nd call is going to be gated on whether your source can be iterated in parallel
22:47
<Justin Ridgewell>
And if your source is a async function* foo(){}, the second .next() call won't do anything until the first .next() call has settled
22:48
<Justin Ridgewell>
So only sync iterable sources (and handwritten async iterable sources) would get the map iterator to parallelize
23:38
<bakkot>
Justin Ridgewell: no issue for it, this is very last-minute
23:39
<bakkot>
but: it is true that you can't pump a generator multiple times; nevertheless the change I propose is enough to get parallelism in iterator helpers
23:41
<bakkot>

i.e.: with the change I propose, if you have

async function* foo(){ yield 0; await sleep(1000); yield 1; }
let it = foo().map(x => fetch(x));
it.next();
it.next()

then the sleep(1000) will run in parallel to first call to fetch, and if the sleep finishes before that fetch does, then both fetchs can happen in parallel

23:43
<bakkot>
unless I'm missing something, anyway. so I do not agree with the "only sync iterable sources (and handwritten async iterable sources) would get the map iterator to parallelize" claim