New Set methods - again

Jordan Harband ljharb at
Sat Jul 29 06:44:36 UTC 2017

Set and Map both already have forEach, and both return undefined, just like

On Fri, Jul 28, 2017 at 6:57 PM, Peter Jaszkowiak <p.jaszkow at>

> > Out of curiosity, what is the rationale behind the choices for which
> non-set-specific, currently-array-only methods to implement?
> One rational is that these are also not Array-specific functions either,
> and serve as much if not more use with sets than with Arrays. I my
> experience, one of the main reasons that people don't use Set and Map is
> because they don't have these helpful utility functions.
> > For example there is `map`, which saves you one array cast and one set
> cast, and `find`, which saves you one array cast, but not, e.g., `reduce`,
> which would also save you one array cast.
> `reduce` doesn't make sense for Sets because it is an ordered operation.
> Sets are unordered, so actually having `forEach` (without the index
> parameter) makes more sense than `reduce`.
> Having these chainable utility functions on `Set.prototype` will make
> dealing with Sets much easier for developers, which will increase their
> usage, making proposals for `Array.prototype.union`, etc less relevant.
> In my opinion, a lot more attention should be paid to building and
> strengthening the standard library of the language instead of adding more
> and more syntax.
> A couple things I'd like to see added / changed with the proposal, though:
> - Why can't `Set.prototype.add` be simply extended to accept multiple
> parameters? This would eliminate the need for `addElements`. If
> `addElements` is going to be a thing, then it should accept a single
> Iterable parameter instead.
> - IMO, `forEach` should be added if all of these other functional methods
> are, but it should return `this` as opposed to `Array.prototype.forEach`
> which returns `undefined`. Alternatively, name it `.each` to signify this
> slight semantic difference.
> - `.flatMap` would be nice to have, flattening Iterables into the new Set,
> and accepting non-iterables as singular values added to the Set
> - I imagine that the concerns over `.union`, `.intersect`, etc being slow
> when accepting multiple Iterables is avoidable by adding optimizations for
> single Sets, multiple Sets, and single iterables
> As an aside to this proposal, you mentioned an alternative of adding some
> of these methods to `%IteratorPrototype%`. I think both are good ideas, but
> the problem is that _really_, only `.map`, `.flatMap`, and `.filter` make
> sense with generic Iterators if you want to maintain laziness.
> Overall, really good stuff, Michał.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list