archives

« Bugzilla Issues Index

#3107 — `Array#find` and `Array#findIndex` should treat holes as `undefined`


`Array#find` and `Array#findIndex` should treat holes as `undefined` rather than skipping them, for consistency with the recent trend in TC39 to treat holes as `undefined`.

Ref. https://github.com/domenic/Array.prototype.contains/issues/15


I am not sure we should make this kind of call without consulting TC39.

But then again I am frustrated that doing so would mean delaying 2 months until we know the answer.


(In reply to Domenic Denicola from comment #1)
> I am not sure we should make this kind of call without consulting TC39.
>
> But then again I am frustrated that doing so would mean delaying 2 months
> until we know the answer.

Meta:

TC39 role is more about making general policy-level design directions. It can't a priori review every one of the thousands of decisions that go into the ES6 spec.

It's the job of feature champions (when there is one) and the editor to make detail level decision, taking into account the current TC39 consensus regarding general design directions.

Once something is in a spec. it can be reviewed and TC39 members and anybody else can file bug reports if they disagree with some detail level design decision. The editor/champions should be able to deal with most such issue. If they think general TC39 guidance or approval is needed they can add a meeting agenda item (you see me do that all the time, but I generally don't stop spec. work waiting for approval). Similarly if a bug reporter disagrees with a decision they can also bring it to TC39.

In this case, I believe that Rick Waldon was the original champion of these methods who wrote a JS level polyfill for the TC39 wiki. I then took it over and wrote the detailed spec. algorithm. I think it was at this level that the hole skipping was introduced. At the time, the general policy we were following, was to main consistency with the ES3/5 era array methods (which generally skipped holes). Subsequently the consensus within TC39 has moved towards "holes: nobody wants them", and we have been spec'ing functions that ignore holes.

This bug is essentially saying that the spec. text for these functions need to be reviewed and possibly revised because of this evolved TC39 design consensus concerning array holes. I'm interested in Rick's thoughts on the matter (as original champion) and I've been watching the es-discuss thread for other negative push back against such a change (so far none). Assuming that push-back doesn't emerge, I'm quite comfortable with making and implementing the decision to eliminate hole-skipping from these functions.


(In reply to Allen Wirfs-Brock from comment #2)
> (In reply to Domenic Denicola from comment #1)
> > I am not sure we should make this kind of call without consulting TC39.
> >
> > But then again I am frustrated that doing so would mean delaying 2 months
> > until we know the answer.
>
> Meta:
>
> TC39 role is more about making general policy-level design directions. It
> can't a priori review every one of the thousands of decisions that go into
> the ES6 spec.
>
> It's the job of feature champions (when there is one) and the editor to make
> detail level decision, taking into account the current TC39 consensus
> regarding general design directions.
>
> Once something is in a spec. it can be reviewed and TC39 members and
> anybody else can file bug reports if they disagree with some detail level
> design decision. The editor/champions should be able to deal with most such
> issue. If they think general TC39 guidance or approval is needed they can
> add a meeting agenda item (you see me do that all the time, but I generally
> don't stop spec. work waiting for approval). Similarly if a bug reporter
> disagrees with a decision they can also bring it to TC39.
>
> In this case, I believe that Rick Waldon was the original champion of these
> methods who wrote a JS level polyfill for the TC39 wiki. I then took it
> over and wrote the detailed spec. algorithm. I think it was at this level
> that the hole skipping was introduced. At the time, the general policy we
> were following, was to main consistency with the ES3/5 era array methods
> (which generally skipped holes). Subsequently the consensus within TC39 has
> moved towards "holes: nobody wants them", and we have been spec'ing
> functions that ignore holes.


These always had "skip holes" semantics:

Array.prototype.find: https://gist.github.com/rwaldron/5079436 (10.b, c, d)
Array.prototype.findIndex: https://gist.github.com/rwaldron/5079427 (10.b, c, d)

As Allen said, this design was chosen to be consistent with the existing Array methods.



>
> This bug is essentially saying that the spec. text for these functions need
> to be reviewed and possibly revised because of this evolved TC39 design
> consensus concerning array holes. I'm interested in Rick's thoughts on the
> matter (as original champion) and I've been watching the es-discuss thread
> for other negative push back against such a change (so far none). Assuming
> that push-back doesn't emerge, I'm quite comfortable with making and
> implementing the decision to eliminate hole-skipping from these functions.


I agree with "holes: nobody wants them" and the committee was anti-holes in 2013 as well. Inconsistencies like this are the sort of thing that end up in blog posts about PHP ;) but maybe now is the time to break from caring about holes.

Allen, here: https://github.com/domenic/Array.prototype.contains/issues/15#issuecomment-51134702 you mentioned consistency with indexOf, are you thinking we should throw it to the wind for both?

Lastly, is everyone here prepared to defend the inevitable mud-slinging that will result in creating inconsistent API semantics? I don't want to be thrown in front of a bus, but otherwise, I'm in.


Thanks for the meta-level help, Allen.

Rick:

> you mentioned consistency with indexOf, are you thinking we should throw it to the wind for both?

Although I would love to experiment with removing hole support (and switching === to SameValueZero) for other array APIs, I don't think anyone was proposing that. We'd want to run some tests in Chrome first, I think. Arv is optimistic about SameValueZero but we didn't contemplate holes.

> Lastly, is everyone here prepared to defend the inevitable mud-slinging that will result in creating inconsistent API semantics? I don't want to be thrown in front of a bus, but otherwise, I'm in.

You'll have my sword.


(In reply to Domenic Denicola from comment #4)
> Thanks for the meta-level help, Allen.
>
> Rick:
>
> > you mentioned consistency with indexOf, are you thinking we should throw it to the wind for both?
>
> Although I would love to experiment with removing hole support (and
> switching === to SameValueZero) for other array APIs, I don't think anyone
> was proposing that.

I'm not asking to change indexOf and wasn't implying that anyone else had either, so either you simply misunderstood what I was asking, or didn't read Allen's comment that I was referring to, so I will copy it here for you:


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

So, when I asked Allen:

" are you thinking we should throw it to the wind for both?"

the "both" I'm referring to are: find AND findIndex


Got it, yes indeed I misunderstood which "both" you were referring to.

But yes, I think that if we are up for it, the strategy should be "all new ES6 methods ignore holes."


(In reply to Rick Waldron from comment #5)
>
>
> "findIndex is specified to be consistent with [].indexOf which skips holes.
> But they are different functions and potentially could differ."
>
> So, when I asked Allen:
>
> " are you thinking we should throw it to the wind for both?"
>
> the "both" I'm referring to are: find AND findIndex

Yes, I'm comfortable with removing hole detection from both.

Note that [].find has a similar consistency issue relative to [].filter, etc. which it is modeled after.

while it is a visible issue for polyfill maintainers, I doubt that any use of these functions will even notice the change. That's the whole point of "holes, nobody wants them".


Agreed. I think polyfill authors will actually appreciate relief from checking holes :)


fixed in rev27 editor's draft


Updated and released in https://github.com/paulmillr/es6-shim/issues/280 .

Pull requested into https://github.com/paulmillr/Array.prototype.find/pull/6 and https://github.com/paulmillr/Array.prototype.findIndex/pull/4


fixed in rev27 draft