Contradicting forbidden extensions for "caller" property on built-in functions?

[anba]

From https://tc39.github.io/ecma262/#sec-forbidden-extensions:

• Other than as defined in this specification, ECMAScript function objects defined using syntactic constructors in strict mode code must not be created with own properties named "caller" or "arguments" other than those that are created by applying the AddRestrictedFunctionProperties abstract operation to the function. [...]. Built-in functions, [...] also must not be created with such own properties.
• If an implementation extends non-strict or built-in function objects with an own property named "caller" [...].

The first bullet point seems to disallow adding "caller" (and "arguments") to built-in functions, whereas the second bullet points adds a restriction when "caller" is present on built-in functions. This seems contradictory to me.

[claudepache]

Presumably, the second bullet applies to non-strict functions only.

[claudepache]

Presumably, the second bullet applies to non-strict functions only.

[bterlson]

I agree it seems contradictory. Additionally, IIRC built-in functions should be as strict-like as possible. Is a simple fix just removing the "or built-in function objects"?

[bterlson]

I agree it seems contradictory. Additionally, IIRC built-in functions should be as strict-like as possible. Is a simple fix just removing the "or built-in function objects"?

[erights]

Precisely speaking, there are three kinds of functions: strict, sloppy, and built-in. I know we are trying to avoid the term "sloppy" in spec language, and I do not argue for it. I agree it sounds too judgemental and informal. But "non-strict" is too misleading because built-in functions are "not strict" but not "non-strict". This is too confusing.

Regarding caller and arguments, they should only be allowed in the initial state of:

• sloppy functions
• as accessor properties of the built-in Function.prototype whose getters and setters only throw.

It must be disallowed in the initial state of all other built-ins and all strict functions. Once created, nothing prevents the user from defining them as normal properties on these functions, but the inherited accessor will inhibit doing so.

[erights]

Precisely speaking, there are three kinds of functions: strict, sloppy, and built-in. I know we are trying to avoid the term "sloppy" in spec language, and I do not argue for it. I agree it sounds too judgemental and informal. But "non-strict" is too misleading because built-in functions are "not strict" but not "non-strict". This is too confusing.

Regarding caller and arguments, they should only be allowed in the initial state of:

• sloppy functions
• as accessor properties of the built-in Function.prototype whose getters and setters only throw.

It must be disallowed in the initial state of all other built-ins and all strict functions. Once created, nothing prevents the user from defining them as normal properties on these functions, but the inherited accessor will inhibit doing so.

[erights]

The second bullet must not include "built-in". I don't know how that got in there.

[erights]

The second bullet must not include "built-in". I don't know how that got in there.

[bterlson]

@erights blame your Editor, probably :-P

I agree with you about tightening the terminology. But the quick fix of removing "built-in" from the 2nd bullet seems good in and of itself, right?

[bterlson]

@erights blame your Editor, probably :-P

I agree with you about tightening the terminology. But the quick fix of removing "built-in" from the 2nd bullet seems good in and of itself, right?

[erights]

@bterlson Right!

[erights]

@bterlson Right!

[allenwb]

Note that the categories of strict functions and builtin functions are not necessarily disjoint. According to https://tc39.github.io/ecma262/#sec-built-in-function-objects a built-in function may be implemented using a strict mode ECMAScript language function.

Also in the spec. text "ECMAScript function objects defined using syntactic constructors in strict mode code...", the word "constructors" is either an original typo or an incorrect change that has been made to the original text. It should be "constructs". That sentence was intended to be about functions objects that were defined via FunctionDeclaration, MethodDeclaration, etc. as distinct from functions defined progamatically or by extra-lingual mechanisms.

[allenwb]

Note that the categories of strict functions and builtin functions are not necessarily disjoint. According to https://tc39.github.io/ecma262/#sec-built-in-function-objects a built-in function may be implemented using a strict mode ECMAScript language function.

Also in the spec. text "ECMAScript function objects defined using syntactic constructors in strict mode code...", the word "constructors" is either an original typo or an incorrect change that has been made to the original text. It should be "constructs". That sentence was intended to be about functions objects that were defined via FunctionDeclaration, MethodDeclaration, etc. as distinct from functions defined progamatically or by extra-lingual mechanisms.

[jmdyck]

the word "constructors" is either an original typo or an incorrect change that has been made to the original text. It should be "constructs"

(The phrase "syntactic constructors" was introduced in draft rev 27 of ES6, when the "Forbidden Extensions" section was added.)

[jmdyck]

the word "constructors" is either an original typo or an incorrect change that has been made to the original text. It should be "constructs"

(The phrase "syntactic constructors" was introduced in draft rev 27 of ES6, when the "Forbidden Extensions" section was added.)

[anba]

FWIW V8 and Chakra currently create built-in functions with own "caller" and "arguments" properties.

[anba]

FWIW V8 and Chakra currently create built-in functions with own "caller" and "arguments" properties.

[erights]

Why? This seems like extra cost for no purpose, in addition to being non-standard.

[erights]

Why? This seems like extra cost for no purpose, in addition to being non-standard.

[allenwb]

Ok, after spend all to much time review the terminology in the current specification, I think all we need is one additional strike-out to @anba's original suggestion:

• Other than as defined in this specification, ECMAScript function objects defined using syntactic constructors in strict mode code must not be created with own properties named "caller" or "arguments" other than those that are created by applying the AddRestrictedFunctionProperties abstract operation to the function. [...]. Built-in functions, [ ...] also must not be created with such own properties.
• If an implementation extends non-strict or built-in function objects with an own property named "caller" [...].

There is an issue about the one remaining issue of AddRestrictionFunctionProperties in the spec. that I will file a separate bug about.

Uupdate: turned "constructor" into "construct"

[allenwb]

Ok, after spend all to much time review the terminology in the current specification, I think all we need is one additional strike-out to @anba's original suggestion:

• Other than as defined in this specification, ECMAScript function objects defined using syntactic constructors in strict mode code must not be created with own properties named "caller" or "arguments" other than those that are created by applying the AddRestrictedFunctionProperties abstract operation to the function. [...]. Built-in functions, [ ...] also must not be created with such own properties.
• If an implementation extends non-strict or built-in function objects with an own property named "caller" [...].

There is an issue about the one remaining issue of AddRestrictionFunctionProperties in the spec. that I will file a separate bug about.

Uupdate: turned "constructor" into "construct"

[claudepache]

The first bullet could be simplified:

• Other than as defined in this specification, a Function object must not be created with own properties named "arguments" or "caller", unless it is a non-strict function created using the Function constructor, a FunctionDeclaration, or a FunctionExpression.

(The “Other than as defined in this specification” refers specifically to Function.prototype.{arguments,caller}; it is premature to strike it now.)

[claudepache]

The first bullet could be simplified:

• Other than as defined in this specification, a Function object must not be created with own properties named "arguments" or "caller", unless it is a non-strict function created using the Function constructor, a FunctionDeclaration, or a FunctionExpression.

(The “Other than as defined in this specification” refers specifically to Function.prototype.{arguments,caller}; it is premature to strike it now.)

[allenwb]

@claudepache The change suggested in #877 eliminates those properties from %FunctionPrototype%. Both sets of changes should be made as a unit.

[allenwb]

@claudepache The change suggested in #877 eliminates those properties from %FunctionPrototype%. Both sets of changes should be made as a unit.

[erights]

I do not remember any agreement to remove them from %FunctionPrototype%

[erights]

I do not remember any agreement to remove them from %FunctionPrototype%

[allenwb]

@erights why would we explicitly need them? Function.prototype is a built-in function, so if they don't have them the forbidden extension restrictions apply.

[allenwb]

@erights why would we explicitly need them? Function.prototype is a built-in function, so if they don't have them the forbidden extension restrictions apply.

[erights]

Perhaps we do not need them. But I'm raising a procedural question: Did we agree to get rid of them? If we had, I can imagine that I may have either agreed or disagreed. Both are plausible enough. But I genuinely do not remember.

[erights]

Perhaps we do not need them. But I'm raising a procedural question: Did we agree to get rid of them? If we had, I can imagine that I may have either agreed or disagreed. Both are plausible enough. But I genuinely do not remember.

[allenwb]

My recollection is that the basic agreement we came to during ES6 was that the poison-pill properties could be eliminated in favor of forbidden extension restrictions. I also don't recall whether we explicitly talked about %FunctionPrototype& but removing those properties from them simply seems like part of implementing that agreement. The fact that they are still there seems like an oversight.

[allenwb]

My recollection is that the basic agreement we came to during ES6 was that the poison-pill properties could be eliminated in favor of forbidden extension restrictions. I also don't recall whether we explicitly talked about %FunctionPrototype& but removing those properties from them simply seems like part of implementing that agreement. The fact that they are still there seems like an oversight.