const formal parameters?

[Brendan Eich]

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