Section 13.2: Rationale for "caller", "arguments" restriction

[Jason Orendorff]

On Tue, May 26, 2009 at 8:05 PM, Mark S. Miller <erights at google.com> wrote:
> To fix this problem, we need one additional bit of poison: If
> arguments.caller or bar.caller would reveal a strict function, they should
> return something harmless instead. I suggest that undefined is a perfectly
> fine harmless value.

No, if adding "use strict" is going to break real-world code, ES5
should throw an exception.

I hope I don't need to justify that stance; we've been there, heard
that, right? (The arguments have to do with workaday web developers
who aren't designing object-capability sandboxes.) I'm not aware of
any silent behavior changes in strict mode as defined in the draft.

Throwing here lets the implementation provide an error message that
clearly blames the caller's strictness. Or, more properly, Mark
himself: "Strict function f can't call nonstrict function g because g
uses arguments.caller, which would expose f to tampering if g is evil.
You can thank Mark Miller for this one." ;-)

(Here the message exposes that f is strict, and even its name, but I
don't see how or why that is to be avoided.)

> If this poison is not swallowed, then SES can still cope by
> translating all function calls to go through a harmless laundry
> function:

With getters and setters that will be quite a bit worse, right? Every
property access would have to be translated into something that
inspects the object rather carefully.

-j