tc39 / proposal-iterator.range

A proposal for ECMAScript to add a built-in Iterator.range()

Home Page:https://tc39.es/proposal-iterator.range/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Iterating on the API Design

codehag opened this issue · comments

commented

One thing that stands out to us is that this is being implemented per number type. We are wondering what the use case would be for bignumber, or indeed for bigDecimal. Perhaps rather than having this as a method on number types, this can live somewhere else. One suggestion was to provide a NumberRangeIterator and if necessary a BigIntRangeIterator. Another thought was that this isn’t really about numbers, but about producing lists. So in this case it might make sense as a method on array, on Iterator, or something similar. We think that this can be made clearer by a better understanding of the use cases for this.

One suggestion was to provide a NumberRangeIterator and if necessary a BigIntRangeIterator.

It is possible to move to Iterator.range

It is possible to move to Iterator.range

It is viable to implement a range function for any partially ordered type so it may be considered preferable for all range functions to be namespaced by their corresponding type and to not special-case any single range function (even if it were the only built-in range function).

// assuming enumerable types default to inclusive-inclusive ranges
String.range("a", "z").next().value === "a";
RgbColor.range([16, 16, 16], [235, 16, 16]).next().value[0] === 16;
Month.range(Month.JANUARY, Month.DECEMBER).next().value === Month.JANUARY;
commented

There is an issue with one of the suggestions that I made here (2020 eh) -- Iterator doesn't exist in the language as a builtin. I think the intention here was on the iterator prototype? That said in our current discussion we are not against Number.range() etc.

The Iterator Helpers proposal exposes it as a global.

Now we throw for non-number/bigint inputs for Iterator.range, which leaves future space if we want to support other data types.

It is viable to implement a range function for any partially ordered type

Yes, that's possible for other languages like Swift or Rust, but in JavaScript, we don't have Ord, PartialOrd, Eq protocols/traits/interfaces on day 1 and it looks like it will also not happen in the future...

I'm closing this issue for housekeeping, but still welcome discussion!