Should we deal with holes?

[domenic]

The operative question is:

var arrayWithHoles = [,,,];
arrayWithHoles.contains(undefined) // true or false?

Additionally there is a consequence for proxies: because holes are checked via HasProperty before doing the GetProperty, a weird proxy could respond inconsistently between the two (e.g. proxy[5] === "foo" but Array.prototype.contains.call(proxy, "foo") === false).

I am leaning toward consistency with other array functions in that we should respect holes.

[arv]

Sad panda...

Since we made find and findIndex skip holes I think we have to continue down this unfortunate path.

[domenic]

Hmm. Do you think it's worth asking es-discuss? We could not skip holes in find and findIndex; it's probably not too late.

[allenwb]

findIndex is specified to be consistent with [].indexOf which skips holes. But they are different functions and potentially could differ.

The recent trend in TC39 has been to treat holes as undefined. But find and findIndex were spec. before that.

I would certainly consider a ES6 bug ticket that said that find and findIndex should treat holes as undefined rather than skiping them.

[mathiasbynens]

I would certainly consider an ES6 bug ticket that said that find and findIndex should treat holes as undefined rather than skipping them.

https://bugs.ecmascript.org/show_bug.cgi?id=3107

[jcrben]

Found this discussion through https://stackoverflow.com/questions/42103761/javascript-array-find-has-problems-with-sparse-arrays.

I haven't been able to find a place which explains the whole reasoning behind this. If the idea is "holes: nobody wants them", then doesn't it make more sense to skip them? The consequence of this is that if I'm consuming an array - such as React props.children, which tends to have holes - I either have to handle the undefined cases with some sort of if check in find callbacks, or I have to run _.compact to remove them.

[domenic]

Skipping holes involves a costly branch check on every iteration.

[caitp]

Skipping holes involves a costly branch check on every iteration.

The branch check happens regardless, since if the element is a hole/array does not have the element itself, a prototype chain lookup is done

[jcrben]

I wonder if I'm missing something given @allenwb's comment to @rwaldron in https://bugs.ecmascript.org/show_bug.cgi?id=3107 that "I doubt that any use of these functions will even notice the change. That's the whole point of "holes, nobody wants them". Seems like people are going to notice having to handle what are essentially nulls - ideally they wouldn't exist, but sadly they often do. But I guess maybe long-term this could encourage people to create dense arrays.

Ended up being able to handle it succinctly with let inputChild = elementTree.props.children.find(element => element && element.type === 'input'); but I'll have to keep my eye out for optimistic iteration.