this value in new Function()

[jfparadis]

Continuing from Agoric/realms-shim#17

As also revealed in test262, the this value in functions created in sloppy mode don't point to the global object. This is a current limitation of the shim.

Edit: the shim documents that all code executes in strict mode. However, as with the post above, it comes as a surprise, because using Function() in the shim creates a function in strict mode, not a function in sloppy mode as expected. Outside of the shim, strict mode is not transitive, and code executing in sloppy mode can evaluate code in sloppy mode. Developers might not be aware of that situation when using Function() or eval(). The PR above was created to fix the this binding, but strict mode has many other impacts on the behavior of Function() that can cause surprises, for example:

Function('a,a', 'return a')(1,2); // throws in strict mode, returns 2 in sloppy mode

We should document clearly along those lines:

eval('(foo')) /* behave like */ (0, eval)('"use strict"; (foo)')
Function('return foo') /* behave like */ Function('"use strict"; return foo')

However, point to note, the shim actually uses:

Function('return foo') /* behave like */ (0, eval)('"use strict"; (function anonymous() { return foo})')

I am not aware of a difference in behavior, but we should also add this to the documentation.

[erights]

I don't understand. It is a limitation of the shim that it does not support sloppy mode at all, so how can it fail a test of sloppy mode behavior?

[jfparadis]

@erights Thanks for pointing this out. I have clarified.

[erights]

eval('(foo')) /* behave like */ (0, eval)('"use strict"; (foo)')

We're trying to reject most code that looks like it contains a direct eval expression. We should reliably reject the code above. We reject it exactly to avoid a runtime surprise, and an incompatability between code successfully running on the shim vs a real implementation.

The strictness surprise still holds. For the real proposal, we should have a strict-only setting anyway. That would maintain compat with what the shim does. The shim could insist that this option be on, since the shim cannot emulate the real proposal when this option is off.

[jfparadis]

Closing this requirement for two reasons:

• All code in SES is strict mode. All code in strict mode has the this value of Function set to undefined, this is according to specs. In plain language:

That means, among other things, that in browsers it's no longer possible to reference the window object through this inside a strict mode function.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

• SES 2.0 supports globalThis and can be used everwhere, and a this value bound to the global object is a duplication.