Function#{caller, arguments} are not non-standard?

[vimirage]

https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-addrestrictedfunctionproperties

The above part of the spec defines both caller and arguments as setters/getters on %Function.prototype%. Currently, the appropriate MDN documentation calls both items "nonstandard;" Their "specifications" sections are empty.

I haven't fully reviewed these relevant sections of the specification; someone should double-check.

[Josh-Cena]

Needs BCD update, indeed

[ghost]

Oops, sure I should've opened there. As it is a purely BCD issue, may someone move this issue?

[Josh-Cena]

Actually I just checked again. The spec doesn't define anything beyond a thrower getter for caller. The actual semantics of caller within the scope of non-strict functions remain an extension by ECMAScript implementations. See also: https://tc39.es/ecma262/#sec-forbidden-extensions

[ghost]

Actually I just checked again. The spec doesn't define anything beyond a thrower getter for caller.

Where is this? I see

3. Perform ! DefinePropertyOrThrow(F, "caller", PropertyDescriptor { [[Get]]: thrower, [[Set]]: thrower, [[Enumerable]]: false, [[Configurable]]: true }).
4. Perform ! DefinePropertyOrThrow(F, "arguments", PropertyDescriptor { [[Get]]: thrower, [[Set]]: thrower, [[Enumerable]]: false, [[Configurable]]: true }).

[[Get]] and [[Set]] are present for both, "arguements" and "caller"?

[Josh-Cena]

Yes, but they unconditionally throw. There's no specification for any other behavior than "they throw". The reason why they can be something other than "throw" is because they are configurable, so implementations can still override them as data properties:

function myFunc() {
  console.log(Object.getOwnPropertyDescriptor(myFunc, "caller"));
}
myFunc();
// {
//   value: [Function (anonymous)],
//   writable: false,
//   enumerable: false,
//   configurable: false
// }

[ghost]

The actual semantics of caller within the scope of non-strict functions remain an extension by ECMAScript implementations. See also: https://tc39.es/ecma262/#sec-forbidden-extensions

That much comes from engine-provided "own properties;" which is unspecified, sure. In contrast, the prototype accessors appear to specified, so to say that the entire thing here is not in the spec, on MDN, is a bit incorrect?

[Josh-Cena]

This is a bit complicated. It's definitely not "non-standard", but the standard doesn't specify anything useful, or anything that's actually presented in documentation. I don't know what to do here TBH. Saying it's standard implies the standard also specifies the behavior when caller doesn't throw, which is not the case.

[ghost]

The reason why they can be something other than "throw" is because they are configurable, so implementations can still override them as data properties:

(Off-topic, but note that even if it were non-configurable on the prototype, then it may still be a data property on the instance.)

[ghost]

This is a bit complicated. It's definitely not "non-standard", but the standard doesn't specify anything useful, or anything that's actually presented in documentation. I don't know what to do here TBH. Saying it's standard implies the standard also specifies the behavior when caller doesn't throw, which is not the case.

There could be extra writing in the Specification section of the content, to clarify this?

[Josh-Cena]

I was more thinking about the status.standards_track property. They are currently false which makes more sense.

[evilpie]

There is a (stalled?) stage 1 proposal for specifying actual caller and arguments accessors.

[OnkarRuikar]

They've been advertised as deprecated for a long time:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features#function
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/caller

In fact we need to mark Function.caller deprecated in BCD to keep it consistent with the Web Docs. And when the Legacy reflection features for functions in JavaScript proposal gets standardized we'll update it in the BCD and the MDN Web Docs.

This is a bit complicated. It's definitely not "non-standard", but the standard doesn't specify anything useful, or anything that's actually presented in documentation. I don't know what to do here TBH.

The standards dropped it a long time ago. So as per the standard it's deprecated. But browsers still support it, which they are free to do. But developers shouldn't rely on it as browsers can drop non standard features easily.

[ghost]

The standards dropped it a long time ago. So as per the standard it's deprecated. But browsers still support it, which they are free to do. But developers shouldn't rely on it as browsers can drop non standard features easily.

Sorry, but it looks like there's a misunderstanding? I refer to the appropriate part of the spec by a link earlier. There are two different sets of behaviours here, one of which is standard, the other isn't.

This is what provokes the confusion.

[ghost]

@Josh-Cena Please, may I ask you to open a discussion to get an agreed upon decision for this issue?

[OnkarRuikar]

The features are on their way out:

• The function AddRestrictedFunctionProperties is being removed : https://github.com/tc39/ecma262/issues/877

  The only remaining use of AddRestrictedFunctionProperties is in CreateIntrinsics. That use is also unnecessary because of the definition of built-in function and the forbidden extension restrictions. Step 12 of that abstract operation should be deleted.

  With those changes, there will not longer be any references to AddRestrictedFunctionProperties so its definition should also be removed from the specification.

• From the article function.caller considered harmful by a V8 engine developer:

  We might continue to support it for a while, but as with arguments.caller that was mentioned in crbug.com/691710, we might also just remove it at some point — for example because we want to be able to escape analyze closures and do scalar replacement for them — so don’t rely on it — obviously also because other JavaScript engines might not support it anyways.

  All of this magic is limited to sloppy mode functions. Strict mode functions have an accessor installed for “caller” via AddRestrictedFunctionProperties that just throws a TypeError on each property access.

  … So “caller” property of sloppy mode function is more or less completely implementation defined behavior.

  That means it's the browsers(JS engines) that continue supporting it, but not the specifications.

[ghost]

The features are on their way out:

• The function AddRestrictedFunctionProperties is being removed : https://github.com/tc39/ecma262/issues/877

  The only remaining use of AddRestrictedFunctionProperties is in CreateIntrinsics. That use is also unnecessary because of the definition of built-in function and the forbidden extension restrictions. Step 12 of that abstract operation should be deleted.

This was four years ago, and shows no progress or consensus on doing so?

• From the article function.caller considered harmful by a V8 engine developer:

This is talking about the non-standard behaviour, again, which I personally don't care whether is documented or not, just that the specification behaviour should be documented.

[queengooborg]

The deprecated status has been fixed in #17548!