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 [email protected] www.isiahmeadows.com On Sun, Jun 24, 2018 at 11:34 AM, Cyril Auburtin <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]>: >>> >>> 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, <[email protected]> >>> 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 >>> >>> >>> [email protected] >>> >>> >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> >>> es-discuss mailing list >>> >>> >>> [email protected] >>> >>> >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >>> >>> >>> >>> >>> -- >>> Jeremy Martin >>> 661.312.3853 >>> http://devsmash.com >>> @jmar777 >>> >>> >>> >>> >>> _______________________________________________ >>> >>> es-discuss mailing list >>> >>> [email protected] >>> >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
