Allen Wirfs-Brock wrote:
1. Array.from already produces sparse arrays from array-likes:
Array.from({ 0: 1, 2: 2, length: 3 }); // [1,,2]
So why it doesn't from sparse arrays?
Perhaps, this is an inconsistency that should be corrected by changing
the spec. to produce [1,2,undefined] in the above case.
No way. The object has length 3 and index 2 has value 2. Why in the
world would Array.from re-index?
The current definition was derived from the legacy algorithms such as
A,p.slice which preserve holes. But as the current consensus is
Array.from does not preserve hole for Iterable arrays then perhaps is
also should preserve them for non-iterable array-likes,
"also should not"?
At the last TC39 meeting, we agreed holes are freakish and should be
discounted in designing new APIs like Array.from (I think; I may be
overstating slightly, but that's the effect).
Whatever we do, we should be consistent among sparse arrays and sparse
arraylikes, it seems to me. Want a bug?
2. Array.from can't be used as generic plain array copy producer.
When this was most recently discussed at [1] the case was made that in
JS sparseness is seldom what anybody actually wants, hence the current
Array.from behavior will be what's desired most of the time. Do you
have any real world use cases in mind that are driving the desire for
Array.from to preserve sparseness?
Use-cases for sparse arrays + copying them would be really helpful.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
