<br><br><div class="gmail_quote">On Tue, Sep 27, 2011 at 4:57 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sep 27, 2011, at 1:21 PM, Dean Landolt wrote:<br>
<br>
> Out of curiosity is there any reason to keep holes the holes around in ObjectLiteral and ArrayLiteral?<br>
<br>
</div>No holes in ObjectLiteral.<br></blockquote><div><br></div><div><br></div><div>Apologies -- I was thinking of the trailing comma, but that's not at issue.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

It's true for ES6, opt-in only, we could change ArrayLiteral to remove holes. This would make early errors for code migrating into ES6 that uses holes, and for authors writing fresh ES6 programs who use holes.<br>
<br>
(Note well that [1,] is an array of length 1, no holes.)<br>
<div class="im"><br>
<br>
> Is there a real usecase (other than rare and trivial minification wins)? Sure, it would be a breaking syntax change but statically detectable and correctable. And it would wipe out a source of bugs rather than doubling down.<br>

<br>
</div>What bugs have you seen due to holes in literas? </blockquote><div><br></div><div><br></div><div>Copy/paste errors, mainly. I'd think the same rationale to justify the trailing comma applies against comma holes in array literals.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I've never seen or heard of any such bugs. </blockquote><div><br></div><div><br></div><div>
I've made this mistake more than once. This kind of bug tends to fail fast so it's not as easy to slip into production, but it's still a runtime error. What's worse, the problem is exacerbated by the fact that tools that lean on Array.prototype.forEach hide the hole, while those that use for(;;) treat it as undefined. I understand that this is a problem with holes in general, and not with ArrayLiteral syntax in particular, but try a console.log on a holy array in, for instance, node and then chrome -- you'll get two VERY different-looking results. The way that console.log in node completely papers over array holes, compounded by the popularity of the comma-first style in that community (which makes a double-comma harder to spot), could be a pretty nasty trap to fall into, even for a js veteran.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The possibility of holes exists without literal syntax support, due to the ability to add elements to an array by assignment to non-contiguous indexes, delete elements, and set length.</blockquote>
<div><br></div><div><br></div><div>Sure, and I'm not arguing for eliminating holes altogether...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I don't see how to get rid of holes created via these means without making runtime-only, not early, errors -- and that's too big a migration tax. It's a source of new bugs that we could avoid by not trying to ban holes.<br>

<br>
So, if we still have holes, is it really worth getting rid of ArrayLiteral support for them? I think not.<br></blockquote><div> </div><div><br></div><div>But are they of any real use for ArrayLiterals? IMHO a hole in a small array (i.e. an ArrayLiteral) is almost always a mistake, and when it's not there's imperative syntax to fall back on. So if there's no good use for it, why enshrine a bad practice with a declarative syntax? The migration tax would trivial, as you alluded.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
BTW, I proposed, as part of Harmony of My Dreams, tuples: <a href="http://wiki.ecmascript.org/doku.php?id=strawman:tuples" target="_blank">http://wiki.ecmascript.org/doku.php?id=strawman:tuples</a> -- no holes, immutable, sane enumeration. Not in Harmony yet.<br>
</blockquote><div><br></div><div><br></div><div>Yeah, those would be nice -- almost as awesome as the records you proposed :)</div><div><br></div></div>