02:22
<littledan>
So in the latest round of JS-is-missing-features discourse, one request that stands out is for Jack Works ‘s Number.range/BigInt.range. I am wondering, how can we move that forward? Is it blocked on anything?
02:24
<littledan>
I remember we had some kind of debate around how exactly arguments should work but everyone was positive about it IIRC
03:00
<bakkot>
I think the main blocker was whether the resulting thing should be one-shot or reusable
03:00
<bakkot>
and we just need to actually decide
03:01
<bakkot>
https://github.com/tc39/proposal-Number.range/issues/17, which is well on its way to being a centithread...
03:02
<ljharb>
indeed i think that's the open question. some iterators are reusable, so one might expect these to be; but most aren't, so one might expect these not to be
03:03
<bakkot>
iterators are never reusable, but many iterables are
03:04
<bakkot>
(iterators being inherently stateful)
03:04
<ljharb>
ah right, that's it
03:21
<bakkot>
from https://twitter.com/tesseralis/status/1622787957261488128, I am actually inspired to do Math.randomInt(), I think
03:21
<bakkot>
where, I guess, it is overloaded based on whether you pass numbers or bigints (and forbids both)
03:22
<bakkot>
or it could be called randomInRange or something
03:22
<bakkot>
though, if Number.range() gave you a re-usable thing, it could be a class instance with a .selectRandom() member...
03:23
<bakkot>
(that is mostly a joke, not a design I would seriously pursue)
03:23
<bakkot>
let getRandomItem = array => array[Number.range(array.length).selectRandom()]
03:53
<bakkot>
ok hear me out: for await.concurrent[2] (item of asyncIter) { ... } to run the body of the for-await concurrently. equivalent to await asyncIter.map(item => {...}).bufferAhead(2).forEach(() => {}) except that the body of the for-await can still do stuff like break and return (which prevent further iterations of the loop from starting, though any which have already started still run to the end of the loop body)
03:58
<littledan>
https://github.com/tc39/proposal-Number.range/issues/17, which is well on its way to being a centithread...
I think I was on the “reusable” side previously but I am now am leaning one shot given what we decided about iterator helpers since then
03:58
<littledan>
You should be able to use an iterator helper directly on a range