repeated parameter names and default values

Allen Wirfs-Brock allen at
Thu Sep 27 10:19:45 PDT 2012

On Sep 27, 2012, at 10:03 AM, Oliver Hunt wrote:

> On Sep 27, 2012, at 9:45 AM, David Bruant <bruant.d at> wrote:
>> ...this is how I discovered that, in non-strict mode, it's possible to
>> define a function where 2 arguments have the same name...
>> Le 27/09/2012 18:19, Allen Wirfs-Brock a écrit :
>>> Consider
>>>  function f(a, b=a, a=3, c=a) {
>> The most positive adjective I can find to describe this like is:
>> "confusing".
>> If I'm ever in a team where a dev writes such a line, I will kill this
>> dev with my bare hands :-)
>> When writing 'c=a', what was the intention of the developer? Maybe the
>> third arg has been renamed to 'a' by mistake during a refactoring,
>> introducing a subtle bug.
>> When using the same argument name several times with default values,
>> what about throwing an SyntaxError at parse time regardless of
>> strictness? It would follow what's been done with strict mode.
> I actually like this, it simplifies the semantics if you say using default arguments disallows duplicate names.  This I think is a livable restriciton as allowing duplicate arguments is basically just a backwards compat feature (so obviously doesn't effect code using defaults).
> I kind of like the idea of disallowing shadowing of argument names if defaults are used as well, but I'm not sure if that would be as low risk to comprehension of behavior.

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. 

Also, at the last meeting there was some significant push back about the load-time costs (startup latency) of early error detection. 


More information about the es-discuss mailing list