On Jun 19, 2008, at 4:07 PM, Mark S. Miller wrote: > As previously mentioned, we've decided to allow "const" variable > declarations into ES3.1 under the "parses on 3/4 browser rule" > (FF,Safari,Opera) since it also aids integrity.
It may parse, but if const turns into var, as in Opera, or is not block-scoped (Firefox and Safari), then no one can count on it until some future releases. This again makes me ask: what's the plan for getting "alpha" implementations of ES3.1 interoperating before the standard is pushed through Ecma to ISO? > However, it's a bit > mysterious how to declare formal parameter variables to be const in a > way that'll parse on 3/4 browsers. It's not mysterious, it is simply not possible. > Both Firefox and Safari reject > > function foo(x, const y) { return [x, y];} > > as a syntax error. However, they both accept > > function foo(x, y) { var y; return [x, y];} > > and they correctly do not treat the "var x;" as shadowing the "x" > parameter variable. So I thought I'd try > > function foo(x, y) { const y; return [x, y];} > > On FF 2.0.0.14 under squarefree this gives a "TypeError on line 1: > redeclaration of formal parameter y". On Safari it parses fine, but of > course that the const-ness is not yet enforced. Would ES4 interpret > the above syntax as declaring the "y" parameter variable to be const? I don't know for sure, but it is plausible since we do not require initialization in the declaration, rather write-once. But does it matter? I think ES3.1 is way over the line of mission creep in trying to get const formal parameters wedged in. They do not parse in any browser implementations. 'const' forward compatibility is iffy to broken due to the different scope rules. It seems to me, and I'm writing this in order to help 3.1 get done and done well, that you really should just cut anything like const parameters now. > If so, what immediate plans do FF and Opera have re this syntax? If > both expect this to parse soon, perhaps we should stretch our 3/4 rule > and permit it? If not, any other suggestions for declaring formal > parameter variables to be const in ES3.1? What good is the 3/4 browsers rule if it allows wildly divergent (or in Opera's case, mapping const to var, meaningless) semantics for const? Getting something to parse, but not behave as proposed (adding integrity), seems like a sure way to deliver secure-looking but insecure-behaving code to certain browsers. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss