New Proposal: Number.range (Yes, range again)

Cyril Auburtin cyril.auburtin at gmail.com
Tue Feb 12 11:43:15 UTC 2019


I'm really cheering for the slice-notation range extension proposed in
https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-421453934

```js
for (const i of Number.range(0, 43)) {
    console.log(i) // 0 to 42
}

const fakeData = [...Number.range(1, 21)].map(x => x ** 2)
```
becomes
```js
for (const i of (0:43)) {
    console.log(i) // 0 to 42
}

const fakeData = [...(1:21)].map(x => x ** 2)
```


On Fri, Jan 18, 2019 at 3:41 PM Jack Works <zjwpeter at gmail.com> wrote:

> Hello everyone, I made a formal proposal
> https://github.com/Jack-Works/proposal-Number.range , welcome to disscuss
> the details in the repo!
>
> On Thu, Nov 29, 2018 at 3:01 PM Jordan Harband <ljharb at gmail.com> wrote:
>
>> It's not a "standard library" unless every part of it has gone through a
>> full standards process.
>>
>> On Wed, Nov 28, 2018 at 8:31 PM Jacob Pratt <jhprattdev at gmail.com> wrote:
>>
>>> I'm not saying we should add it on to that proposal, but rather saying
>>> that I think more effort should be put into a standard library where things
>>> like this don't need to go through a full standards process. That's just my
>>> opinion, and borderline on-topic for this specific suggestion.
>>>
>>> I'm absolutely in favor of having a `range` method, it's just _where_ it
>>> should be that I differ.
>>>
>>> Jacob Pratt
>>>
>>> On Thu, Nov 29, 2018 at 4:29 AM Jack Works <zjwpeter at gmail.com> wrote:
>>>
>>>> Oh, I'm not here to find out how to implement a range in detail. That's
>>>> the trivial things, I want to first make it become a stage 0 proposal, then
>>>> we can discuss if we need some overload or how to deal with the edge cases.
>>>> Ps, does Pratt mean we should add it as a standard library in the stage
>>>> 1 standard libraray proposal?
>>>>
>>>> On Thu, Nov 29, 2018, 12:18 Jacob Pratt <jhprattdev at gmail.com> wrote:
>>>>
>>>>> Quick, simple TypeScript range function (with overloads, of course).
>>>>>
>>>>> ```
>>>>> export function range(end: number): IterableIterator<number>;
>>>>> export function range(start: number, end: number):
>>>>> IterableIterator<number>;
>>>>> export function range(start: number, end: number, step: number):
>>>>> IterableIterator<number>;
>>>>> export function* range(start: number, end?: number, step?: number):
>>>>> IterableIterator<number> {
>>>>>   // overload #1
>>>>>   if (end === undefined) {
>>>>>     [start, end, step] = [0, start, 1];
>>>>>   }
>>>>>
>>>>>   // overload #2
>>>>>   if (step === undefined) {
>>>>>     step = Math.sign(end - start);
>>>>>   }
>>>>>
>>>>>   // ensure we have the appropriate types
>>>>>   if (typeof start !== 'number' || typeof end !== 'number' || typeof
>>>>> step !== 'number') {
>>>>>     throw new TypeError('all parameters must be of type number');
>>>>>   }
>>>>>
>>>>>   while ((start < end && step > 0) || (start > end && step < 0)) {
>>>>>     yield start;
>>>>>     start += step;
>>>>>   }
>>>>> }
>>>>> ```
>>>>>
>>>>> IMO, we should focus on building up a JavaScript standard library that
>>>>> has tons of useful utilities like this, rather than continue to add methods
>>>>> onto namespaces. Perhaps that's just me, though.
>>>>>
>>>>> Jacob Pratt
>>>>>
>>>>> On Wed, Nov 28, 2018 at 9:33 PM Tab Atkins Jr. <jackalmage at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I end up writing a range function in virtually every project I use, so
>>>>>> yeah, I think this is worthwhile.
>>>>>>
>>>>>> My own preferences, based on Python precedence:
>>>>>>
>>>>>> Number.range(end) === Number.range(0, end, 1)
>>>>>> Number.range(start, end) === Number.range(start, end,
>>>>>> Math.sign(end-start))
>>>>>> Number.range(start, end, step) => {
>>>>>>   if start < end && step > 0: yield all (start + k*step), for k from 0
>>>>>> to infinity, less than end
>>>>>>   elif start > end && step < 0: yield all (start + k*step), for k from
>>>>>> 0 to infinity, greater than end
>>>>>>   else: yield nothing
>>>>>> }
>>>>>>
>>>>>> So:
>>>>>> * [...Number.range(5)] evaluates to [0, 1, 2, 3, 4]
>>>>>> * [...Number.range(0)] evaluates to []
>>>>>> * [...Number.range(-5)] evaluates to []
>>>>>> * [...Number.range(1, -3)] evaluates to [1, 0, -1, -2]
>>>>>> * [...Number.range(-3, 1)] evaluates to [-3, -2, -1, 0]
>>>>>> * [...Number.range(1, 1)] evaluates to []
>>>>>> * [...Number.range(0, 10, 5)] evaluates to [0, 5]
>>>>>> * [...Number.range(0, 10, -5)] evaluates to []
>>>>>>
>>>>>> ~TJ
>>>>>>
>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190212/dc772eb7/attachment.html>


More information about the es-discuss mailing list