Whether keywords should be allowed as names in function declarations

Brendan Eich brendan at mozilla.com
Tue Jan 20 14:54:43 PST 2009


On Jan 20, 2009, at 2:09 PM, David-Sarah Hopwood wrote:

>> You replied selectively -- not nice.
>
> Given that my position was that the case of "match[ing] an interface
> across a language bridge" was not plausible in the case of function
> declarations, I didn't think that the rest of the paragraph was
> relevant enough to quote. No other examples of cases in which it would
> be useful for a function name to be a keyword were given.

Excuses, excuses :-P.


> Consider
>
>  function delete(foo) { ... }
>  ...
>  delete(bar);
>
> Here the programmer has forgotten that 'delete' is a keyword. If  
> keywords
> are not allowed as declared names, then this mistake can be reported  
> at
> the function declaration. If they are allowed, then the mistake  
> cannot be
> reported (because "delete(bar)" is valid syntax), and will cause  
> unintended
> behaviour.

Good point (see, worth the time to reply -- at least in my opinion --  
so: thanks!).

This seems not to be an issue in practice -- no bugs filed yet -- but  
it is disturbing.


> The costs are:
> - preventing implementations from reporting errors when a keyword is
>   used unintentionally. This is a significant cost, especially for new
>   programmers who may not be entirely familiar with the full keyword  
> set.

In practice it has not proven so for JS1.7 users, but who knows? You  
could be right that it would be a significant cost with more user  
testing. I wouldn't assert that it "is significant" yet without  
evidence.

What is now clearly significant, thanks to your reply, is the lack of  
diagnostics for certain keywords when used as "callees" in "call  
expressions". That reminds me of why opt-in was needed to add 'yield':  
because it's used a formal parameter name and (IIRC) as a function name.


> - 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 ;-).

/be


More information about the Es-discuss mailing list