What strict mode eval declarations did we really ban?
2009/2/10 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>
Waldemar's Mountain View notes said: - Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
Did we really mean that only function scoped declarations are so restricted? What about var declarations in strict global code?
What about function declarations? Can they have "eval" as their function name if they are contained in strict function code or in strict code in general.
The simplest story is that "eval" is banned from all declarations in strict mode code.
This is one of those happy cases where simplest is best. The net effect is that ES3.1-strict can be explained as if "eval" is a keyword.
However, now that I think a little bit more about, it would be reasonable to say that any strict mode declaration of "eval" is an EvalError. I was going to say it was a SyntaxError but EvalError is more specific and in line with its ES3 heriatage.
From: Mark S. Miller [mailto:erights at google.com] Sent: Tuesday, February 10, 2009 7:25 PM To: Allen Wirfs-Brock Cc: es-discuss Subject: Re: What strict mode eval declarations did we really ban?
2009/2/10 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com<mailto:Allen.Wirfs-Brock at microsoft.com>>
Waldemar's Mountain View notes said: - Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
Did we really mean that only function scoped declarations are so restricted? What about var declarations in strict global code?
What about function declarations? Can they have "eval" as their function name if they are contained in strict function code or in strict code in general.
The simplest story is that "eval" is banned from all declarations in strict mode code.
This is one of those happy cases where simplest is best. The net effect is that ES3.1-strict can be explained as if "eval" is a keyword.
On Tue, Feb 10, 2009 at 7:50 PM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
However, now that I think a little bit more about, it would be reasonable to say that any strict mode declaration of "eval" is an EvalError. I was going to say it was a SyntaxError but EvalError is more specific and in line with its ES3 heriatage.
How ironic ;).
Mark S. Miller wrote:
2009/2/10 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>
The simplest story is that "eval" is banned from all declarations in strict mode code.
This is one of those happy cases where simplest is best. The net effect is that ES3.1-strict can be explained as if "eval" is a keyword.
Agreed.
Allen Wirfs-Brock wrote:
However, now that I think a little bit more about, it would be reasonable to say that any strict mode declaration of "eval" is an EvalError. I was going to say it was a SyntaxError but EvalError is more specific and in line with its ES3 heriatage.
Doesn't matter to me whether it is EvalError or SyntaxError. However, are there other identifiers that should be banned by the same rule? For example, 'arguments' behaves like a keyword in some respects.
Declaration binding instantiation creates an array object for a function only if the function does not have any explicit declarations named "arguments". However, there is currently no strict mode restriction on such declaration.
Adding such a restriction would be a feature addition to what, at this point, should be a frozen feature set (I consider the related ongoing discussions to be clarification of intent for already committed features rather than new feature proposals). I'm not dogmatic about things like this, but at this point there probably should be pretty overwhelming consensus before we add any new feature.
On Wed, Feb 11, 2009 at 8:22 AM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:
Declaration binding instantiation creates an array object for a function only if the function does not have any explicit declarations named "arguments". However, there is currently no strict mode restriction on such declaration.
Adding such a restriction would be a feature addition to what, at this point, should be a frozen feature set (I consider the related ongoing discussions to be clarification of intent for already committed features rather than new feature proposals). I'm not dogmatic about things like this, but at this point there probably should be pretty overwhelming consensus before we add any new feature.
Agreed. And I doubt we will get such consensus quickly for arguments. But in case we can, I'll put in my vote: I'm in favor of imposing a similar strict mode restriction on "arguments".
Waldemar's Mountain View notes said: - Agreed to disallow the use of "eval" as the name of a local variable, function parameter, etc. in strict mode.
Did we really mean that only function scoped declarations are so restricted? What about var declarations in strict global code?
What about function declarations? Can they have "eval" as their function name if they are contained in strict function code or in strict code in general.
The simplest story is that "eval" is banned from all declarations in strict mode code.