Whether keywords should be allowed as names in function declarations

Brendan Eich brendan at mozilla.com
Tue Jan 20 21:30:40 PST 2009

On Jan 20, 2009, at 8:26 PM, David-Sarah Hopwood wrote:

>>> - programs that rely on this change will fail to work on some ES3
>>>  implementations, when renaming the function would have been  
>>> sufficient
>>>  to allow them to work (if there is no other reliance on ES3.1).
>> This says the spec should not allow extensions that add
>> keyword-unreserving contexts. I'm sure you agree ;-).
> I didn't say that this was a sufficient cost by itself to preclude  
> such
> extensions. In the case of allowing property names to be keywords, for
> instance, we have a greater benefit because both the definition (in
> object literals) and its use (in member expressions) can be allowed.

There's no way to quantify this greater benefit, at least as far as I  
know. So it's more precise to say that there's no hazard of the kind  
you pointed out where

function typeof(...) {...}
... typeof(x) ...

passes without error in old or new implementations (assuming keyword  
function names are allowed).

The above could even be argued to be a feature for "upgrading" certain  
keywords, provided they are unary operators always used (by  
convention) with parenthesized operands! Again we have zero  
quantification by which to conclude that this is less or greater a  
benefit vs. cost. But it's a cost unique to the "keyword function"  
approach, I agree. It does not come up with keywords as context- 
qualified property names where the context is unambiguos for uses as  
well as definitions.

So what do we really know?

- JS1.7 and JS1.8 have shipped without drawing bugzilla reports about  
the problem you pointed out.
- On the other hand, it's not clear how useful keyword functions are  
if so named only for pretty-printing or self-calling reasons -- again  
no evidence has been gathered or quantified.
- We do know that hazard you cite is unique to the "keyword function"  
proposal; it does not arise in the case of qualified property names in  
object initialisers and dotted expressions.

Using 1 bit of estimation, rounding conservatively, it seems the  
benefits and costs of a prototype implementation of keyword functions  
are both 0, and the hazard-cost of keyword functions compared to  
qualified keyword properties is 1.

So again I agree we should leave out keyword functions. I was hoping  
to get further agreement on the 3.1 spec prohibiting keyword functions  
even as an extension (in chapter 16, if it does not already prohibit  
this kind of extension). This prohibition can be debated independently  
of any concern about compatibility with existing browsers.

In any case what's in 3.1 seems good to keep, and I didn't mean to  
question it. I hope you are not suggesting qualified keyword  
properties be removed. More below on general compatibility arguments  
against expressiveness extensions.

> Nevertheless, this *is* a significant compatibility/interoperability  
> cost.
> IE7 doesn't appear to allow any keyword as a property name in either
> object literals or member expressions, for instance, so it will be a
> while before the ability to do this in ES3.1 is actually useful on the
> web [*].

That's true of a number of ES3.1 features that can't be emulated fully  
or at all. It's true of any future Harmony extensions. It's inevitable  
in my view, and the best we can do is to keep the standard alive and  
evolving in usable utility, not over-minimizing pessimistically, with  
web developers participating and pushing browser vendors for greater  
use of new versions over time.

> That's a consideration for any extension, but more so for
> extensions that don't add any expressiveness to the language, and that
> a program could have avoided with a simple local renaming.

Expressiveness is worth something too. Weighing the trade-off against  
short-term considerations is usually fatal to any longer-term progress.

We are not in this for the short-term, or there wouldn't be a new  
version of IE in 2006 after none was planned following IE6 Service  
Pack 1 in 2003, or a new version of ECMAScript in 2009. Five years  
ago, before Firefox 1.0, these things seemed out of reach. Look how  
far we've come since then. We should think ahead five years and build  
on what has happened.

> [*] User adoption of new IE versions seems painfully slow:
>    <http://www.w3schools.com/browsers/browsers_stats.asp>,

That's just one source, and it may not distinguish IE6 from fake-IE6  
(see http://en.wikipedia.org/wiki/Usage_share_of_web_browsers, AVG  

IE6 peaked in the high 80% share in 2002-2003 and fell to just above  
20% at the end of last year. For many lead-user or highly monetized  
sites, IE6's share is so low that the sites' web developers do not  
support it. I know a lot of Enterprise use remains behind firewalls.  
But five more years of web browser and advanced web content competion  
will continue the trend of the last five years, and put IE6 out of our  
misery -- probably sooner, maybe in two years.

>    The only way I see that improving is if Microsoft change
>    their browser upgrade policy.

Whether they do this or not, we should keep designing for the longer  
term and not preemptively sacrifice expressiveness for short-term  
compatibility, especially ersatz compatibility in the case of non- 
syntactic extensions that add new semantics which cannot be emulated  
on old browsers. Such ersatz compatibility can lead developers into  
making a security hole where none existed.


More information about the Es-discuss mailing list