Consider first-class type (i.e. 'NumberRange' or 'Interval') vs. a 'range' method

[rbuckton]

In tc39/proposal-slice-notation#19 (comment) I suggested adding something similar to the C# Index and Range types which could also address these use cases with a more flexible API than an overloaded Number.range method.

An example of these APIs can be found here:

• Index - https://github.com/esfx/esfx/blob/c50876e542bc73df907b5e3ff4ef95ad656cb3b3/packages/interval/src/index.ts#L23
• Interval - https://github.com/esfx/esfx/blob/c50876e542bc73df907b5e3ff4ef95ad656cb3b3/packages/interval/src/index.ts#L107

The advantage of this (or a similar) API is that it provides a convenient place to attach functionality like .includes(value), as well as a place to provide different ways to generate an Interval without relying on possibly confusing overloaded behavior like Number.range(10).

[Jack-Works]

I'm trying to avoid adding a global name on the globalThis but if everyone is okay with that, I'm also okay to change the API design.

On the other hand, the slice notation can behave the following way

// Literal `Range` syntax:
let range = 1:3; 
// -> range = Number.range(1, 3);

And I will add @@slice, @@geti on the return value. (Currently, it is immutable so @@seti won't be involved)

[tabatkins]

I'm opposed to a syntax that would require a new just to create a range; it's visual noise that distracts from what should be a lightweight operation. If the function can be called without a new, then I have no opinion on whether it's an object or just a plain iterator.

[rbuckton]

There's no reason Interval(1, 3) couldn't be synonymous with new Interval(1, 3). If we had value types, I imagine something like Interval would be a value type (in which case the new would be unnecessary/would result in boxing like new Boolean vs Boolean).

[Jack-Works]

Value type for range? Do you mean the record and tuple or a separate new value type? (I don't think it should be a value type)

[tiansh]

If so, I would prefer NumberSequence or NumberStream. So you can make functions like:

• NumberSeq.range(from, to, step = 1), NumberStream.range(to);
• NumberSeq.count() // output [0, 1, 2, 3, ...]
• NumberSeq.iterate(initial, iterateFunc) // output [initial, iterateFunc(initial), iterateFunc(iterateFunc(initial)), ...]`
• NumberSeq.repeat(seed) // output [...seed, ...seed, ...seed, ...], or [seed, seed, seed, ...]
• ...

But not need to limit to NumberRange.

We can also make the class work for non-numeric types, and rename it as Sequence or Stream. This may be too far from what this spec want to do. But API like this make more sense to me.

[hax]

1. I like the idea of being value type. It allow us use === (for example, ^1 === ^1 could return true if Index is value type)

2. I also like the idea of range.includes(), but it doesn't require range to be value type, so it could be a separate issue. I believe Make Number.range() return re-usable value #17 already cover that.

3. I think we still need separate classes (or value types) for different range (interval), aka. NumberRange, BigIntRange, IndexRange. Note they could be Number.Range, BigInt.Range, Index.Range so we don't need adding too many names to globalThis.

4. Consider possible range literals, (1n:3n) should be BigInt.Range(1n, 3n), (1:^1) should be Index.Range(Index(1), Index(1, {fromEnd:true}), but what about (1:3), whether it create Number.Range or Index.Range?

[littledan]

Value types are pretty far out. If we had them now, it could make sense. I think this proposal fills an urgent need, and we shouldn't wait on value types for them. I think this proposal will be very very useful with range iterables (if we have them at all) being objects. Most of the time, you won't really use the iterable much at all; you'll just get its iterator. The Temporal proposal is making a similar tradeoff.

[gsathya]

What would happen on property access with this new built in type?

const r = Range(1, 3);
[1, 2, 3, 4, 5][r] 
// [2, 3] or undefined?

[Jack-Works]

(Note your code have ASI problem)

I don't think we should overwrite the behavior of [ ]. (I think this belong to the slice notation proposal)

[gsathya]

(I think this belong to the slice notation proposal)

Why?

[Jack-Works]

Maybe things like [r.from:r.to] or other notation. I'm not preferring to overload the [expr]

[gsathya]

I'm not preferring to overload the [expr]

I agree.

I'm not sure we'd want different behavior for slice notation depending on where it's used. Not a fan of this:

const r = 1: 3; // creates a Range object
[1, 2, 3, 4, 5][r]; // undefined
[1, 2, 3, 4, 5][1: 3]; // [2, 3]

I'd prefer this:

const f = 1:3; // SyntaxError
const r = Range(1, 3);
[1, 2, 3, 4, 5][r]; // undefined
[1, 2, 4, 5, 5][r.from: r.to]; // [2, 3]
[1, 2, 3, 4, 5][1: 3]; // [2, 3]

[obedm503]

Perhaps as part of a different proposal, it would be good to introduce some sort of getter/setter protocol. If Array.prototype[Symbol.getter] exists, it is called and gets passed whatever is between []. If not it does regular property access. It add more extensibility to the language.

[mpcsh]

late to this issue, but wanted to re-up the notion of a .includes method. I'm opposed to the idea of reusing a range, but I think that's not necessarily a problem; for example, Rust's iterator semantics allow for a .includes method, which simply consumes the iterator. I don't see why we couldn't do that here, as a way to allow this convenience method without cracking open the reusability discussion.

EDIT: striking discussion on reusability, as I think it's actually just orthogonal to this issue. regardless, curious to hear thoughts on .includes specifically.