<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style="font-size:11pt; font-family:Calibri,sans-serif">Duplicate parameters are quite common in the following case:<br>
<br>
callSomething(function (_, _, whatIActuallyCareAbout) {});</div>
</div>
<div dir="ltr">
<hr>
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">From:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif"><a href="mailto:brendan@mozilla.com">Brendan Eich</a></span><br>
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">Sent:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif">12/29/2012 20:16</span><br>
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">To:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif"><a href="mailto:erights@google.com">Mark S. Miller</a></span><br>
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">Cc:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif"><a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a></span><br>
<span style="font-size:11pt; font-family:Calibri,sans-serif; font-weight:bold">Subject:
</span><span style="font-size:11pt; font-family:Calibri,sans-serif">Re: excluding features from sloppy mode</span><br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Mark S. Miller wrote:<br>
> On Sat, Dec 29, 2012 at 1:26 PM, Brendan Eich<brendan@mozilla.com>  wrote:<br>
>> Mark S. Miller wrote:<br>
>>> 2) Make a micro-mode, adding yet additional mode switching in order to<br>
>>> supposedly avoid the complexity of dealing with one mode switch.<br>
>> No, you are using micro-mode as an epithet without actually defining it in a<br>
>> meaningfully different way from "new semantics for new syntax".<br>
><br>
> If I have a function<br>
><br>
>      function foo(w, x, y) {<br>
>        var [a, b] = y;<br>
>        // use of a,b but not y in rest of body<br>
>      }<br>
><br>
> and I change it to<br>
><br>
>      function foo(w, x, [a, b]) {<br>
>        // use of a,b but not y in rest of body<br>
>      }<br>
><br>
> I have preserved its meaning. The change seems local to the individual<br>
> parameter. But if I have a function<br>
><br>
>      function foo(x, x, y) {<br>
<br>
Yes, but let me interject: no one does this. It's insane. A latent bug <br>
or a quirk that deserves an early error.<br>
<br>
>        var [a, b] = y;<br>
>        // use of a,b but not y in rest of body<br>
>      }<br>
><br>
> and I change it to<br>
><br>
>      function foo(x, x, [a, b]) {<br>
>        // use of a,b but not y in rest of body<br>
>      }<br>
><br>
> now my second function is rejected.<br>
<br>
Yes, with an early error.<br>
<br>
Since no one does duplicate formal parameter in practice, this early <br>
error is a good thing (tm).<br>
<br>
>   This demonstrates the<br>
> "mode-nature" if you will of this rule.<br>
<br>
Rather, new syntax gets new semantics.<br>
<br>
We've shipped this for years in SpiderMonkey. I believe Rhino matches. <br>
No one uses duplicate formals, so no one has ever complained.<br>
<br>
>   The rejection must be<br>
> explained by a function-wide change of what the language accepts,<br>
<br>
No, not function-wide! Purely function-head, more specifically the <br>
parameter list.<br>
<br>
>   even<br>
> though I changed only one parameter.<br>
<br>
Parameter changes in ES6 have effects on the list. We don't allow more <br>
than one rest parameter at the end, for example. Given<br>
<br>
   function f(a, b, ...r) {...}<br>
<br>
If I try adding another ellipsis:<br>
<br>
   function f(a, ...b, ...r) {...}<br>
<br>
I get an early error. Another good thing(tm), and no less local than <br>
destructuring parameters banning duplicate params.<br>
<br>
> OTOH, if destructuring is accepted only in strict code, then the<br>
> rejection of destructuring is explained only by strictness rules.<br>
<br>
"rejection of duplicate parameters"<br>
<br>
Yes, that's the way to explain it via (1). And you are right that the <br>
condition for rejection of duplicate formals becomes more than "in <br>
strict code". It has to be "in strict mode || destructuring present in <br>
parameter list".<br>
<br>
However, since duplicate formals are a do-not-want, always-a-bug, <br>
freakish rarity bestowed on ES1 during standardization, this extra <br>
disjunct is a spec-internal complexity, not anything users must worry about.<br>
<br>
I'm prepared to give up on the ban of duplicate formals when <br>
destructuring parameters are present, if that will get rid of your <br>
objection to "micro-modes". I don't recall anything else like this case. <br>
We arrived at it mainly to simplify implementation in SpiderMonkey, but <br>
again: users do not notice because no one uses duplicate formals.<br>
<br>
>> Are arrow functions, syntax and definite semantics, a "micro-mode"? If not,<br>
>> why not? I suspect you are using a mental desugaring spec but there's no<br>
>> such spec. Allen has to deal with whether arrows have [[Construct]] (we<br>
>> decided no, because |this| is bound to outer |this|). Is that a<br>
>> "micro-mode"? I say no.<br>
<br>
Did you have a thought here? It may be we're arguing only about the <br>
"destructuring parameter bans duplicate parameters" special case.<br>
<br>
/be<br>
_______________________________________________<br>
es-discuss mailing list<br>
es-discuss@mozilla.org<br>
<a href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br>
</div>
</span></font>
</body>
</html>