On Sep 13, 2013, at 9:18 AM, Brendan Eich <bren...@mozilla.com> wrote:
>> Oliver Hunt <mailto:oli...@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. > > * 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 > > * 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. 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) > > 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 > > The real issue that Andreas's proposal addressed was the insanity of body > declarations hoisting to be in view of default. But it sounds like we do not > have consensus on whether or not that's crazy. >> >> This would produce a consistent and easy to follow semantic for default >> evaluation, it doesn't introduce any new types of scope, nor does it require >> any new concepts (temporal dead zones, etc) to be learned by a developer who >> just wants default parameter values. > > The hoisting issue still hits your non-consensus actual parameter count > (arguments.length) thing, though. When reading the function in source order, > one sees a default expression. Mentally moving the defaulting to the body > means that hoisted body decls trump outer bindings for names in the > expression, indeed. But mentally moving is the objectionable part -- > cognitive load, and non-source-order evaluation (more hoisting). > > Hoisting need not perpetuate itself this way. We can do better, or at least > Andreas proposes that we do. I'm sympathetic. > > 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. >> >> 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. > > /be > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
