Do we need an indicator whether the range was completely fulfilled?

[shaedrich]

Imagine, we have a range like this:

const iterator = range(0, 4, 2)

Then we get

[ 0, 2, 4 ]

and both iterator.done and, let's say, iterator.exhausted would be true.

ALright, now image this:

const iterator = range(0, 5, 2)

This would also yield

[ 0, 2, 4 ]

but now, iterator.done, while iterator.exhausted would be false. A hypothetical iterator.remainder would be 1.

Would anyone need that? Has this already been considered?

[ljharb]

what is iterator.exhausted? (that's not part of this proposal) why would you want that?

[shaedrich]

It's essentially syntactic sugar, if you will, for

const max = 5
const iterator = Iterator.range(0, max, 2)
const r = [ ...iterator ]
iterator.exhausted = r.at(-1) === max

resp.

const max = 5
const iterator = Iterator.range(0, max, 2)
const r = [ ...iterator ]
iterator.remainder = max - r.at(-1)
iterator.exhausted = iterator.remainder === 0

[ljharb]

Iterators aren’t inherently finite, and if they’re “done” then they’re always exhausted.

[shaedrich]

It's not about finite or infinite. Infinite would mean, they are never done. But what I propose is to determine if done was a spot landing/precision landing.

[ljharb]

What's the use case for needing to know that range(0, 5, 2) is done, but never hit 5? we don't have that right now in for loops, for example.

[Jack-Works]

Yes, I wonder the use case of this

[shaedrich]

What's the use case for needing to know that range(0, 5, 2) is done, but never hit 5? we don't have that right now in for loops, for example.

But for loops are usually different. If there's no manual break or return inside, they will be exhausted. range(), on the other hand, will do that automatically, and sure, when you have a literal range, you would know, but once you pass variables to it, you might not.

I mean, in #64, it's currently discussed that Iterator.range(0n, Infinity, {inclusive:true}) should throw. iterator.exhausted would just be the non-throw variant of it. And this wouldn't be the first API to have both options for devs to choose.

[ljharb]

you can use variables in a for loop too, and in both cases you can check your own first.

I don't see why it would ever throw.

[shaedrich]

you can use variables in a for loop too

Yeah, but that was only part of my answer.

in both cases you can check your own first

That's the point of syntactic salt. Syntactic sugar doesn't introduce anything that wasn't possible before but removed unnecessary boilerplate.

I don't see why it would ever throw.

My reference was primarily meant to indicate that I'm not the only one discussing this.

[ljharb]

I'm still not seeing a concrete use case for why you care if the end condition is specifically hit or not.