Discuss
  • const formal parameters?

const formal parameters?

# Mark S. Miller (17 years ago)

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. 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. 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? 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?

# Brendan Eich (17 years ago)

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.

# Mark S. Miller (17 years ago)

On Thu, Jun 19, 2008 at 5:39 PM, Brendan Eich <brendan at mozilla.org> wrote:

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.

[out of order]

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.

So long as it parses, that would allow code to version sniff and adapt, with conditionals, to different execution environments. That's why we're using the "parses on 3/4 browsers" criterion. (Thanks Maciej, I think)

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?

I don't know if the ES3.1 WG has discussed how to get to ISO. I've only participated in discussions re an Ecma std, for which we're planning to leverage the ES4 RI. What would you suggest for 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.

I was hoping that the

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

syntax I suggested was close enough to possible. However, I just verified that it doesn't parse on Opera 9.5 either, so I give up on this one.

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.

I certainly appreciate the sentiment, and I agree on this case. It just seems weird to be able to declare local variables const but not be able to declare parameter variables const. Oh well, it's not the weirdest thing that we've decided to live with.

# Brendan Eich (17 years ago)

On Jun 19, 2008, at 8:17 PM, Mark S. Miller wrote:

So long as it parses, that would allow code to version sniff and adapt, with conditionals, to different execution environments. That's why we're using the "parses on 3/4 browsers" criterion. (Thanks Maciej, I think)

"Adapt" means "do without" on Opera, in this case. But IE is out
already, so I guess the user-agent sniffing should put Opera in the
same no-const branch that IE gets.

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?

I don't know if the ES3.1 WG has discussed how to get to ISO. I've only participated in discussions re an Ecma std, for which we're planning to leverage the ES4 RI. What would you suggest for ISO?

Ecma specs go to ISO via the JTC1 fast-track process, mostly
polishing and picking nits. The time to get implementor and user
feedback is before Ecma stamps the standard as "done". This was
obviously the case for ES1, and ES2 followed implementations adopting
features such as do-while and switch. ES3 had some innovations beyond
what implementations had already supported -- some of these did not
work so well while others were ignored by vendors of already-shipped
code.

I certainly appreciate the sentiment, and I agree on this case. It just seems weird to be able to declare local variables const but not be able to declare parameter variables const. Oh well, it's not the weirdest thing that we've decided to live with.

const parameters are supported in ES4, FWIW.

# Maciej Stachowiak (17 years ago)

On Jun 19, 2008, at 8:17 PM, Mark S. Miller wrote:

So long as it parses, that would allow code to version sniff and adapt, with conditionals, to different execution environments. That's why we're using the "parses on 3/4 browsers" criterion. (Thanks Maciej, I think)

I think my only involvement in the 3/4 rule was asking what it
actually meant. I'm not sure who deserves credit for originating it.

, Maciej