Whether keywords should be allowed as names in function declarations

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Jan 20 14:09:17 PST 2009

Brendan Eich wrote:
> On Jan 20, 2009, at 11:06 AM, David-Sarah Hopwood wrote:
>> I don't see any relevant arguments in followups that would contradict the
>> position above.
> 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.

>  In such a case you could certainly use an object initialiser or
> assignment (doesn't matter which), but you couldn't give the function
> the intrinsic name 'delete'. Named functions have their uses, not so
> much for recursive calls as for better diagnostics and less inscrutable
> pretty-printing results.

Reporting a name that cannot be used to reference the function in most
contexts, is arguably more inscrutable than requiring the programmer
to change it to something that can be directly referenced.

Allowing keywords as function names makes for worse diagnostics in cases
where the use of a keyword was unintentional. Consider

  function delete(foo) { ... }

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

'delete' in this example could also be 'if' (as also pointed out by MarkM),
'new', 'this', 'throw', 'typeof', 'while', and probably 'yield' in a
future ES version.

For other keywords, an error might be reported at the point of use (if
that statement is executed), but that is a less useful place to report it,
and the error message may be less clear.

(I'm aware that implementations that support such names as an extension
will not report the mistake in any case. I don't think that is a good
enough reason to standardize this behaviour.)

> It costs next to nothing for implementations or the spec to allow
> ordinarily reserved keywords to be used after 'function', and it
> benefits some users who already make use of this ability in JS1.7 and
> up. The low cost and utilitarian benefit is the basis for standardization.

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.

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

David-Sarah Hopwood

More information about the Es-discuss mailing list