Add Function#caller and Function#arguments to Annex B

tc39 / ecma262

Status, process, and documents for ECMA-262

https://tc39.es/ecma262/

Other

15.03k stars 1.28k forks source link

Add Function#caller and Function#arguments to Annex B #562

Open claudepache opened 8 years ago

claudepache commented 8 years ago

... because I doubt that any browser vendor would kill them.

I have written a strawman here: https://github.com/claudepache/es-legacy-function-reflection

Some notes:

Function#caller and Function#arguments are specced as configurable getters on Function.prototype rather than properties of individual functions, following Firefox's example.
Moreover, a basic realm check is performed (step 3 of GetTopMostExecutionContextIfLeakable), so that after those properties are deleted, they cannot be recovered from another realm.
As arguments.caller is not supported by any browser, I think that step 9 of CreateUnmappedArgumentsObject can be removed.
arguments.callee is currently specced in ECMA262 as unavailable for sloppy-mode functions with nonsimple parameter list. Question: Should Function#arguments and Function#caller be disabled for those functions as well?

ljharb commented 5 years ago

@claudepache what does edge do, and what did IE do?

jorendorff commented 5 years ago

Whether Firefox should change behaviour depends, I think, on how hard it is needed for web compatibility.

Every difference in behavior is a web compatibility risk, so there's some pressure to converge regardless of what TC39 does.

But standardizing things to improve web compatibility and the developer experience is TC39's mandate, right? By all means, please go ahead and do it. Since implementations currently differ, you can have your pick of behavior. Just don't leave this unspecified for our (Mozilla's) benefit. We'll implement the standard.

claudepache commented 5 years ago

@ljharb Both IE and Edge throw a TypeError.

ljharb commented 5 years ago

In that case, it seems like half the web does one thing, and half another, so we can pick what either pair of them do, as long as at least one of the other two are willing to change?

erights commented 5 years ago

Since we still have a choice, throwing the TypeError is much better. We should specify that.

ljharb commented 5 years ago

Would someone like to make a PR, reach out to the engines that will need to make a change, and write test262 tests?

claudepache commented 5 years ago

In fact, Safari does throw (like Firefox and Edge) when the caller property is about to reveal a strict-mode function: I've been tripped by PTC. A non-tail-call-sensitive test case is:

// "don't use strict"
function g() { "use strict"; var r =  f(); return r; }
function f() { return f.caller; }
g();

I’ve tested some other cases, see: https://github.com/claudepache/es-legacy-function-reflection/issues/1; from those results, I’ll amend my proposal.

claudepache commented 4 years ago

Hi,

I have completed the analysis of how browsers currently implement .caller and .arguments, and I have modified the proposed spec in a way that is both as near as possible to what implementations do, while being as secure and consistent as possible.

The good news is that implementations are remarkably consistent between each other, except for small — but sometimes important — details; so that they’ll need to do minimal changes.

@erights is intending to present the proposal at the next meeting.