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

Reply via email to