Holes in Tuples

[caitp]

I'm wondering if Holes, in the sense of #[ , , , ] would be allowed in Tuples or forbidden, and if a Hole is allowed, does loading from a hole always evaluate to undefined, or does it result in loading elements from higher up in the prototype?

[littledan]

I'd suggest that we not support holes in tuples, but we permit this syntax, with the interpretation that this is syntax sugar for making the element undefined.

[rickbutton]

I heavily lean towards not allowing holes at all (but would be fine with the syntax sugar for undefined. Are there any technical reasons to allow real holes beyond wanting them to behave like objects?

[caitp]

Are there any technical reasons to allow real holes beyond wanting them to behave like objects?

Not per se, but I didn't recall seeing it in README.md and wasn't sure how it was planned to be modeled. It sounds like there's a lot of concensus around "allow the syntax, but don't allow holes".

Would you be interested in taking it a step further and saying that element access never traverses the prototype for records (even if accessing an element beyond the length of the tuple)?

[ljharb]

Any element access on a non nullish primitive boxes to an object first, so that would also mean the object form had that behavior.

[littledan]

@ljharb yes, that's what we are talking about. Clearly Record and Tuple wrappers are exotic objects, just like String wrappers. I don't see how this is relevant to the discussion.

[ljharb]

It wasn't clear to me that that was clear in the thread, so I was confirming/clarifying.

[bakkot]

I think holes should be forbidden and also syntactically prevented. I don't see a good reason to allow the syntax but give it semantics which are extremely subtly different; holes are confusing enough already.

Note that the most relevant difference between holes and explicit undefined is not, to my mind, whether the corresponding prototype property is accessed - people rarely put numeric values on Array.prototype, so that doesn't matter that much to me (except insofar as it affects optimizability). Rather, the difference is whether methods like forEach are invoked for the hole. In arrays, they are not: [,].forEach(console.log) does not log anything. That's pretty confusing. But if #[,].forEach(console.log) does log, that will cause confusion as well, especially if anyone starts using the syntax for records and then expects it to behave the same for arrays.

Better that #[,] just be illegal.

[dcporter]

Better that #[,] just be illegal.

I disagree — I would rather have the consistency of the undefined shorthand working for both, than consistency with fiddly forEach oddities. (Everyone agrees holes are terrible. :) )

[bakkot]

It is not a shorthand for undefined in array literals. It is a completely different, horrifying thing.

[dcporter]

It’s a very closely related, mostly the same, horrifying thing. It’s horrifying in its nearly-sameness.

[bmeck]

I know we have had some people ask about if the prototype should be null for these types. If it is, this doesn't seem to be an issue?

[ljharb]

I think the [[Prototype]] of Record.prototype and Tuple.prototype could certainly be null.

[littledan]

@bakkot gave some pretty convincing arguments above for banning holes in Tuple literals. Can we conclude on his proposal and prohibit these syntactically (as an "early error" I imagine)?

[bmeck]

@littledan I do not believe my comment was off topic as it does have a position on how this specific issue could be avoided. Discussing if this issue is something that needs to be addressed is intertwined with other issues and removing the ability to cross reference issues seems a bit much.

[littledan]

@bmeck OK, I un-hid them. I do want to be careful about repeating arguments across different threads, though; we have a tendency to do that.

[rickbutton]

I agree with @bakkot/@littledan that allowing the syntax as a shorthand for undefined introduces a sharp edge (imo) around things like forEach, that I think would outweigh the benefit of allowing the shorthand. If no-one sees any significant flaw in this approach I would love to resolve this issue with that conclusion (make #[,] a syntax error)

[dcporter]

I would love to resolve this issue with that conclusion (make #[,] a syntax error)

As happened with arrays, this syntax could be added on later if folks want to push it separately, right? If so then I'm fine with that.

[rickbutton]

Yes I believe that making it a syntax error now would allow us to add the shorthand in the future if so desired.

[rricard]

I started drafting spec text. The current grammar being drafted will not even allow holes so it will yield a syntax error

[yuchi]

Will it allow for trailing commas though?

[rricard]

Current grammar allows trailing commas

[yuchi]

Thank you for the clarification

[Mouvedia]

Obviously, let [, b] = #[1, 2]; remains valid, correct?

[rricard]

Yes, you're still using the same destructuring syntax, there is no special-casing here because of the tuple