Continuing woes in reading the ES6 spec language

Brendan Eich brendan at mozilla.com
Fri Sep 13 11:55:00 PDT 2013


> Oliver Hunt <mailto:oliver at apple.com>
> September 13, 2013 6:39 PM
> On Sep 13, 2013, at 9:18 AM, Brendan Eich<brendan at mozilla.com>  wrote:
>
>>> Oliver Hunt<mailto:oliver at apple.com>
>>> September 13, 2013 6:11 PM
>>> Okay so we were discussing among ourselves, and we thought that a sane "desugaring" for
>>>
>>> function f(x=expr) {
>>> ...
>>> }
>>>
>>> would be
>>>
>>> function f(x) {
>>> if (arguments.length<  1) x=expr;
>>> ...
>>> }
>> ES6 has two things that go against this, already in consensus among those at the meetings (we miss you shiny fruit-company people ;-):
> More of the consensus discussion need to happen on es-discuss, this is the only standards body i'm involved in that seems to require details be hammered out in F2F meetings.  It's one of the things I find disappointing about the ES standard - the avoidance of es-discuss when discussing language features makes it actively difficult for input from the wider dev community.

Some of us live on es-discuss and make it to only two of three days of 
TC39 meetings. Others work very hard during meetings taking notes. I 
think we could do better but (here you go :-/) you need to pay attention 
more, because *we've been over this decision on es-discuss*. See

https://mail.mozilla.org/pipermail/es-discuss/2012-June/023402.html

et seq. in the thread.

So if you missed it in es-discuss, no foul -- that happens. But don't 
blame TC39!

>> * You can have default parameters before parameters without defaults.
> The spec explicitly states that any parameter without a default, but after another parameter that does have a default assignment implicitly has a default property of undefined

That's not the issue, and it's vacuously true of JS today. The 
counterexample you seek is

function foo(x = 42, y) { return [x, y]; }

foo(undefined, 99); // ES6 draft says [42, 99]

Your proposed arguments.length test would (were arguments allowed in a 
function with new formal parameter syntax) fail to default x to 42. in 
that foo call.

>> * You can pass undefined to trigger defaulting -- this is important for composition / delegation.
> No, it's a terrible feature :D i'm unaware of any language that supports arbitrary ordering of arguments.

No one said arbitrary ordering. Are you thinking of keyword (named) 
parameter to actual argument binding? No one proposed that for JS, 
object literals sucked all air from any such would-be feature.

> The elegant solution i saw someone mention was
>
> function f({option1, option2, option3} = {option1:default option1, ...}) { … }
>
> That gives you nicely named parameters!  (It was this example that made me start looking at default parameters in the first place)

Yup, I think you misread me.

The undefined-as-defaulting-sentinel decision goes back to the 2012 
es-discuss thread cited above, ratified by TC39 at at least this 
meeting, and reconfirmed many times:

https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html

>> I think we all agree that new formal parameter syntax gets rid of arguments. Yay!
>
> If only we could kill it everywhere!  My proposal was to simply ban arguments as an identifier entirely

Wat.

We can't break JS. Are you thinking we have opt-in versioning? We don't. 
1JS, dude.

>> Temporal dead zones are indeed weirder but perhaps pay for themselves by catching errors. But is it an error to use an outer name binding in the default expression, given its position in the formal parameter list? I think not.
>
> The problem with temporal dead zones is that they lead to weird behaviour in edge cases, and almost all of them should be syntactically identifiable as errors up front.  The problem is that you can only _almost_ get syntax checked behaviour upfront because eval.

Still, they're in ES6 -- again many es-discuss threads and what seems 
like at least every July TC39 meeting for two years running, we've 
reconfirmed/rejustified this.

>>> We also felt that if you use default or rest parameters we should consider that as a opt out from the magic arguments object, and just poison the arguments identifier entirely (no read, write, or declare)
>> SpiderMonkey's prototype implementation does this, and I asserted above that ES6 specs it. Not so?
>
> The ES6 spec (as far as i can read it) only bans declaration of parameters/vars named "arguments" it doesn't ban reading them.

Are you talking about strict-mode code? Sloppy mode allows arguments for 
any name, for backward compatibility.

Allen ack'ed in this thread that we have a draft bug: just a missing 
static semantics check where new formal parameter syntax is used to 
proscribe arguments usage in the body.

/be


More information about the es-discuss mailing list