domenic at domenicdenicola.com (2014-03-02T22:41:14.123Z)
Allen Wirfs-Brock wrote: > 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? > 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.
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