Ranges

[Isiah Meadows]

I'd love to see ranges, but only implemented as iterables. But in reality,
we really should start pushing for a proposed `iterutils` module (or
similar) that has all this widely useful stuff that doesn't really have a
place in the global scope, but are still generally useful. Granted, this is
currently blocked on the pipeline operator proposal IIUC (not on TC39, but
I've heard/read things hinting at it), but that's the main thing that
really needs to happen.

-----

Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com

On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <cyril.auburtin at gmail.com>
wrote:

> What I'd really like is something to avoid `Array.from({length: n}, (_, i)
> => ..)`
> It's very common to use it nowadays
>
> on the + side, it's a wider feature than range, the callback is more
> powerful to build any kind of ranges
>
> but it feels quite hacky and verbose. you can make a typo on 'length', and
> have to use the second callback argument.
>
> I'd like a lot a `Array.whateverNameAsShortAsPossible(4, i => 2*i+1) //
> [1, 3, 5, 7]` I think `Array.build` was proposed a long time ago (
> array.build)
>
> Le mer. 14 déc. 2016 à 21:28, Alexander Jones <alex at weej.com> a écrit :
>
>> IMO this is quite unnecessary syntax sugar. Python has everything you
>> could need here without special syntax.
>>
>> On Wed, 14 Dec 2016 at 16:55, Jeremy Martin <jmar777 at gmail.com> wrote:
>>
>>> While slightly more verbose, the previously suggested `...` syntax does
>>> have a superficial consistency with the spread operator. Both perform an
>>> expansion of sorts, which has a subtle elegance to it, IMO.
>>>
>>> On Wed, Dec 14, 2016 at 4:02 AM, Hikaru Nakashima <
>>> oao.hikaru.oao at gmail.com> wrote:
>>>
>>> I understand.
>>> I hope to find a good form of literals.
>>>
>>> Is there a fact that literals are easier to optimize in the following
>>> cases?
>>>
>>> ```
>>> for (let i of [1 to 5]) { ...... }
>>> vs
>>> for (let i of Array.range(1, 5)) { ...... }
>>> ```
>>>
>>> If so, it seems that we can attract vendors' interests.
>>>
>>> 2016-12-14 17:29 GMT+09:00 Andy Earnshaw <andyearnshaw at gmail.com>:
>>>
>>> I think you'd be lucky to even get to that stage.  Vendors aren't keen
>>> on any kind of backwards incompatibility in new specs and trying to get
>>> this to stage 4 with such a glaring one would be practically  impossible.
>>>
>>>
>>> It's not just the incompatibility either.  You also introduce an
>>> inconsistencies where things like `[1..toFixed(2)]` doesn't mean the same
>>> as `[ 1..toFixed(2) ]`. That kind of thing is just confusing to developers.
>>>
>>>
>>> When you consider these things, it becomes clear that it's not practical
>>> to change the language this way for such a small benefit.
>>>
>>>
>>>
>>> On Wed, 14 Dec 2016, 03:00 Hikaru Nakashima, <oao.hikaru.oao at gmail.com>
>>> wrote:
>>>
>>> Oh, I understood it.
>>> It looks like serious problem, but it is may not actually.
>>> If this spec change doesn't break web, we can introduce this idea?
>>>
>>>
>>> _______________________________________________
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jeremy Martin
>>> 661.312.3853
>>> http://devsmash.com
>>> @jmar777
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> 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/20180624/f687b101/attachment-0001.html>