Normative: Prefix RangeIterator with Numeric

[Jack-Works]

1. Rename RangeIteratorPrototype to NumericRangeIteratorPrototype.
2. Rename RangeIteratorPrototype.inclusive to RangeIteratorPrototype.isInclusiveEnd.

(This is not related to #44 or #45, not affecting the main API shape but do observable)

[ljharb]

Why “numeric”? What other kind of range would be implied?

What does “isInclusiveEnd” mean versus “isInclusive”?

[Andrew-Cottrell]

Why “numeric”? What other kind of range would be implied?

The Numeric prefix may be worthwhile if plausible future proposals might define

• DateRangeIteratorPrototype
• StringRangeIteratorPrototype
• EnumRangeIteratorPrototype

[ljharb]

Are those plausible?

[Jack-Works]

Why “numeric”? What other kind of range would be implied?

If we're going to have String ranges in the future, we won't collide the name.

What does “isInclusiveEnd” mean versus “isInclusive”?

It means, the property only indicates the end is inclusive or not. The start is always inclusive

[Andrew-Cottrell]

Are those plausible?

I don't know, but I can conceive of them. However, if I wanted to range over some ordered type, one approach would be to map a suitable range of numbers; for example

let animals = Number.range("🐀".codePointAt(), "🐉".codePointAt(), {inclusive: true}).map(String.fromCodePoint);
for (let animal of animals) console.log(animal); // 🐀 🐁 🐂 🐃 🐄 🐅 🐆 🐇 🐈 🐉

which could conceivably be written as

let animals = String.range("🐀", "🐉"); // function might also accept an optional `Intl.Locale` or `Intl.Collator`
for (let animal of animals) console.log(animal); // 🐀 🐁 🐂 🐃 🐄 🐅 🐆 🐇 🐈 🐉

Perhaps those prototypes are unnecessary; even if they are conceivable.

[devsnek]

String.range('a', 'z') could theoretically exist.

[ljharb]

@devsnek i don't see how, would that include ü, for example?

[devsnek]

@ljharb in the event I propose String.range I'll answer that question :)

[Jack-Works]

I'll revert the rename on isInclusiveEnd because I want to match the name in the options bag

[ljharb]

To restate: i don't think any non-numeric ranges are viable, and i think the "numeric" prefix is unnecessary.

[Jack-Works]

To restate: i don't think any non-numeric ranges are viable, and i think the "numeric" prefix is unnecessary.

Why not? Why can't we have a "Temporal" range like Temporal.range(day1, day3) in the future?

[ljharb]

Temporal.Duration already exists, there’d be no need for it on Temporal itself.