On Sep 27, 2012, at 10:26 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> My original intent was to apply such rules and the current spec. draft >> actually has some of these restrictions. However, those parts were written >> before 1JS emerged and the consensus around 1JS seems to be try to >> gracefully extend the current ES5 semantics to encompass such new feature >> without early error restrictions. > > We have discussed here doing what SpiderMonkey already does: the strict-mode > ban on duplicate parameter names when you opt into destructuring. This is > entirely consistent with 1JS, and it makes the language better for users and > implementors, from what I've seen. > >> Also, at the last meeting there was some significant push back about the >> load-time costs (startup latency) of early error detection. > > That's an issue for sure but we talked last week about less-than-early errors > for some things. OTOH even a stripped down parser or "reader" must cope with > some name binding checks per ES5 strict mode (as well as recognizing "use > strict";). That ship sailed. Same goes for duplicate property names in object > literals in strict mode. > > The real objection was to full name def/use analysis, which this is not. > Duplicate formals are pretty easy to detect and you have to throw an early > error for any such given a "use strict"; (later!) in the same function.
So the purpose my original posting is achieved. I'm all for statically disallowing many of these "stupid" cases and I think it is fine to do the checks at "first call" rather than load-time (a off-line static linter could be more aggressive in reporting such errors). Since the consensus here seems to be the same, I'll take that approach as I update the spec. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
