repeated parameter names and default values

[Allen Wirfs-Brock]

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