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.

[oleedd]

Imagine, we have a range like this:

const iterator = range(0, 4, 2)

Then we get

[ 0, 2, 4 ]

But the proposal has this explanation:

for (const i of Iterator.range(0n, 43n)) console.log(i) // 0n to 42n

So inclusive or not?

[tabatkins]

We can assume from the examples that OP intended an inclusive range (and should have passed the option for that). That detail isn't relevant to their request, however.

The important thing that hasn't been answered yet is providing a concrete use-case for what this functionality (knowing whether your last value "hit the end" or not, and possibly how much was "left over") would be used for in practice.

[oleedd]

That detail isn't relevant to their request, however.

It is directly relevant. Because the upper limit is unattainable if exclusive range.

We can assume from the examples that OP intended an inclusive range

But this proposal example shows that it is exclusive (42n, not 43n). It should be stated in the proposal more precise - by words. Now it looks like it hasn't been decided yet.

[tabatkins]

Again, it's clear from their example output that they intended it to be an inclusive range. Misspelling the precise code to generate that isn't an important detail here.

The Iterator.range proposal is indeed precise about this; I'm not sure what you're confused about here. Are you assuming that the OP is one of the authors of this repository?

[oleedd]

I mean that the description of this proposal doesn't have "inclusive"/"exclusive". And nothing is said about options for this there.
Usually proposal descriptions have all important details to understand how it will work. But this one - no.