I thought it was agreed that the function passed to
Set.prototype.forEach would be called with 3 arguments, the value, the
value again and the context object. This is so that one can use the
same function for Array.prototype.forEach, Map.prototype.forEach and
Set.prototype.forEach.
Yes, I've reopened the bug for this:
https://bugs.ecmascript.org/show_bug.cgi?id=591
Isn't an adapter supporting the use case as simple as:
(v,s) => f(v,v,s) ?
More generally, is it really a good idea to treat Sets as
"Arrays without duplicate elements"?
Supporting this idea constrains implementations (no small sets as
bitmaps, one needs consistent iteration order, too). And with type
support making inroads in JS tools and implementations, what is
this idea going to do to types?
Array.forEach : ((Element, Number, Array[Element]) => void) => void
Map.forEach : ((Element, Key, Map[Key,Element]) => void) => void
Set.forEach : ((Element, ???, Set[Element]) => void) => void
Instead of fixing ??? to Element, which won't work if the Array
callback uses its index parameter, one might want to use a type
representing "don't use this", to avoid accidental late errors when
using Array callbacks in Set forEach.
In languages with support for unevaluated parameters, one would
pass in an expression that would throw an explicit error if evaluated.
Even with explicit adapters, one cannot always gloss over the
differences, so what is the advantage of enshrining one fixed
implicit adapter in the API?
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
