repeated parameter names and default values

[Brendan Eich]

Allen Wirfs-Brock wrote:
> On Sep 28, 2012, at 9:16 AM, Brendan Eich wrote:
>
>> Allen Wirfs-Brock wrote:
>>> I generally use "static" to mean: solely based upon analysis of the program text without any dependencies upon runtime state. That's my criteria for classifying something as part of the language's static semantics" (which includes early errors).
>> Ok so far.
>>
>>> All ES errors (including early errors ) end up being reported at runtime.
>> No, here you redefine "runtime" from any useful definition. Of course stages nest or recur fractally but in the browser, if a script loads and the first evaluation in it runs, you've reached "runtime". And ES5 is quite clear that early errors -- including in nested functions, *including in strict function*, must stop the whole script from reaching runtime.
>
> It depends upon whether you are considering the "runtime" of an individual script or the "runtime" of an application.

Clinton-esque. :-/

It depends on nothing. We know how scripts load today, how ES5 mandates 
early errors. If you have a break to a non-existent/typo'ed label deep 
in a function nest, the entire containing script fail-stops at compile 
time without side effects.

This is a useful property, it's not something to throw away or try to 
equate to function-wise tardy errors.

> Most ES applications are composed of multiple scripts  so the "early" point prior to script runtime for a particular script is still usually somewhere in the middle of the "runtime" of the application.

Yes, obviously -- but you seem to be equating that with a much finer 
grained tardy error semantics that litters the heap with miscompiled 
functions.

I think that's pretty wrong.

>>>    It's only a matter of how much, if any, execution is permitted before such errors are reported.
>> You're still dodging the "use strict"; ES5 precedent point.
>
> I said:
>
> On Sep 28, 2012, at 8:46 AM, Allen Wirfs-Brock wrote:
>
>> On Sep 27, 2012, at 1:40 PM, Brendan Eich wrote:
>>
>>> More, you didn't respond to my "use strict"; point. Are you going to change whether duplicate parameters with "use strict"; in the function prologue throw an early error, or not?
>> My default is to make no changes to existing ES5 semantics without careful consideration of the impacts. If we defer reporting of these new errors that we are discussing to a latter point during execution it might be reasonable to also defer reporting of the ES5 "use strict" derived errors.  That would presumably be a compatible change as it relaxes an error condition.

No, you may break code that today works by a script fail-stopping 
without effect, intentionally or accidentally. It's an incompatible 
change and it won't fly.

Moreover, you are not considering the other alternative: add more early 
errors in ES6 because they are no more onerous than ES5 strict checks 
already in the field, and they build on sunk costs in those implementations.

The proximate example is duplicated formals in conjunction with new 
parameter syntax (destructuring, defaults). If I missed a reply from you 
on this, sorry. It would be good to get agreement on true early errors 
for duplicated parameter names when mixed with new parameter syntax. 
Doug, Andreas, and others (I bet Mark) agree.

>>   But first we need to decide whether or not we are going to even have the concept of "deferred early error" .

We do! Where's the list of candidate early error cases? Cc'ing Luke.

/be