1152313 - Possible inconsistency in where "delete" can be used as an identifier

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

> document.fonts.delete
function delete() {
    [native code]
}

> function delete() {}
SyntaxError on line 1: function statement requires a name

Is it intentional that 'delete' can be used as a dot (lookup?) identifier but not as a function name (binding?) identifier? It seems strange to allow one but not the other.

Comment 1

[Jesse Ruderman]

Even weirder, it's allowed for getter functions but not for normal functions.

> uneval({get delete (){}})
({get delete (){}})

(I also noticed that getter functions are allowed to have quoted function names, e.g. containing spaces.)

Comment 2

[Boris Zbarsky [:bzbarsky]]

Per ES spec, "function delete() {}" is in fact a syntax error, but "delete" can be used as a property name.  Same for other keywords (try "if").

The relevant bit for the syntax error is that both FunctionDeclaration and FunctionExpression use BindingIdentifier (see <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions>) and the following bits from <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-identifiers-static-semantics-early-errors>:

  BindingIdentifier : Identifier
  Identifier : IdentifierName but not ReservedWord

Comment 3

[Boris Zbarsky [:bzbarsky]]

For getter functions, the relevant syntax definition is at http://people.mozilla.org/~jorendorff/es6-draft.html#sec-method-definitions and says:

  MethodDefinition[Yield] :
    get PropertyName[?Yield] ( ) { FunctionBody }

Note PropertyName, not BindingIdentifier.  PropertyName can be all sorts of stuff, including identifiers, strings, computed property names.  For example, you can do:

> uneval({ get [5+7]() {} })
"({get 12 () {}})"

Comment 4

[Jeff Walden [:Waldo]]

Not a bug, behaves according to spec.  People have argued about allowing reserved words as the identifier in function expressions and declarations, and for a time we even allowed it (dubiously, IMO, because it means in the latter case you can have functions *you can't even use*), anticipating an ES* change, but TC39 backpedaled.

Which is to say, get it in a spec first.  Not a bug right now.