Is "NewTarget" defined anywhere? If so, can we get a <dfn>?

[domenic]

I've always found the "NewTarget" notation confusing. (And especially, it's unclear to me when to use that versus GetNewTarget(). It seems like only syntax parts of the spec use the latter?) As far as I can tell it's a floating undefined ambient thing that all abstract operations have access to?

It would be great to give it a <dfn> and thus create autolinks to something defining this notation.

As an example of what I'm talking about, see basically every constructor in the spec, e.g. https://tc39.github.io/ecma262/#sec-symbol-description.

[annevk]

https://tc39.github.io/ecma262/#sec-built-in-function-objects seems to define it. E.g., https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects refers to that section.

[annevk]

https://tc39.github.io/ecma262/#sec-built-in-function-objects seems to define it. E.g., https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects refers to that section.

[domenic]

Bleh, kind of; that's a dumb definition though as it just says "The NewTarget value is x when y, and z when w". It doesn't say what NewTarget actually is (a value that can be used in some algorithms, I guess?). But with that pointer maybe I can whip up a pull request.

[domenic]

Bleh, kind of; that's a dumb definition though as it just says "The NewTarget value is x when y, and z when w". It doesn't say what NewTarget actually is (a value that can be used in some algorithms, I guess?). But with that pointer maybe I can whip up a pull request.

[annevk]

Ideally we just define where engines actually store it I guess.

[annevk]

Ideally we just define where engines actually store it I guess.

[claudepache]

If we want to be super-explicit, we could be more complete in many introduction texts, e.g. in 19.4.1.1 Symbol([ description ]):

When Symbol is called with optional argument description, the following steps are taken:

replacing it with:

When Symbol is called with optional argument description, the this value, and the NewTarget value, the following steps are taken:

In those algorithms, "NewTarget" is about as implicit as "this value".

[claudepache]

If we want to be super-explicit, we could be more complete in many introduction texts, e.g. in 19.4.1.1 Symbol([ description ]):

When Symbol is called with optional argument description, the following steps are taken:

replacing it with:

When Symbol is called with optional argument description, the this value, and the NewTarget value, the following steps are taken:

In those algorithms, "NewTarget" is about as implicit as "this value".

[allenwb]

@claudepache is exactly correct here. When specify the semantics of a built-in function "NewTarget" and "this value" refer to state provided by the [[Construct]] or [[Call]] that invoked the built-in. This is explained in paragraph 3 of 9.3.

The specification challenge here is that built-ins are not necessarily implemented as ECMAScript functions so the mechanisms (GetNewTarget() and ResolveThisBinding()) that are used to define the semantics of the new.target and this syntactic elements of an ECMAScript function can't be used within an algorithm that specifies the behavior of a built-in. So, https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects provides conventional language for use in accessing those values within such algorithms.

"NewTarget" and "this value" should only be used in the top-level algorithms that defined built-ins. They should not be used in other abstract operations (because paragraph 3 of 9.3 doesn't generally apply to abstract operations). If an abstract operation that is used to factor the definition of one or more built-ins need to access those values they should be explicitly passed as parameters to the abstract operation (for example see https://tc39.github.io/ecma262/#sec-regexpalloc).

[allenwb]

@claudepache is exactly correct here. When specify the semantics of a built-in function "NewTarget" and "this value" refer to state provided by the [[Construct]] or [[Call]] that invoked the built-in. This is explained in paragraph 3 of 9.3.

The specification challenge here is that built-ins are not necessarily implemented as ECMAScript functions so the mechanisms (GetNewTarget() and ResolveThisBinding()) that are used to define the semantics of the new.target and this syntactic elements of an ECMAScript function can't be used within an algorithm that specifies the behavior of a built-in. So, https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects provides conventional language for use in accessing those values within such algorithms.

"NewTarget" and "this value" should only be used in the top-level algorithms that defined built-ins. They should not be used in other abstract operations (because paragraph 3 of 9.3 doesn't generally apply to abstract operations). If an abstract operation that is used to factor the definition of one or more built-ins need to access those values they should be explicitly passed as parameters to the abstract operation (for example see https://tc39.github.io/ecma262/#sec-regexpalloc).