What is `[].constructor.constructor` when executed inside the fresh `eval`?

[bakkot]

I see that global.eval('() => {}').constructor is supposed to be the fresh Function, not the "outer" one. Presumably this is accomplished by rewiring the function syntax inside of the fresh eval so that the [[Prototype]] of new functions is the fresh Function. So far so good. But what about global.eval('[]').constructor.constructor? Is that not still the outer Function?

[ljharb]

I'm not sure why it would be - global.eval !== eval, so it's not really "rewiring" the syntax, it's just evaluating the syntax as if it were, say, inside an iframe.

[bakkot]

Then what is it? The proposal says it only creates new versions of eval and the four Function constructors. So what could global.eval('[]').constructor be except for the outer Array? And if so, how could global.eval('[]').constructor.constructor be anything other than the outer Function?

[mhofman]

This is a mistake in the explainer and current slides. There is a single %FunctionPrototype% shared by all globals, which is the [[Prototype]] of all Function instances. The Function constructor is different in each global, and evaluates with a top level scope being the corresponding global object.

(async () => {}).constructor === new Global().eval("async () => {}").constructor;
newGlobal.Function.prototype === globalThis.Function.prototype;

new Global().eval("new Function().constructor !== Function");

[naugtur]

Around the time this issue was created we spotted the issues and were fixing the slides.
I just moved the slide fixes over to the README now.

Thanks for spotting this and let us know if you find inconsistencies in the updated content.

[naugtur]

@kriskowal Do we want to address [].constructor.constructor being the same and Function.constructor.constructor being where there's room for repairs in the writeup?

@bakkot
It is the case that without special treatment of intrinsic (.*)Function prototypes and constructors it is possible to bypass the basic confinement offered by new Global.
That's where motivating use-cases diverge:

1. The basic security-unrelated isolation we're finding useful for AI-generated code doesn't need the special treatment of shared prototypes,
2. Implementing all of Compartment in user code would require specific repairs to the prototype and constructor fields on (.*)Function among other tweaks.

new Global enables both.

[ljharb]

I'm very confused by a "new Global" that doesn't have its own copies of all builtins.

[mhofman]

It's not a new Realm. It is just a new top evaluation context / scope in the existing realm.

[kriskowal]

I'm very confused by a "new Global" that doesn't have its own copies of all builtins.

Understandable. This is new Global in the sense that each new Compartment has a new global in the Compartment proposal, and this is the smallest necessary cut to produce the full expressivity of Compartment without litigating all of Compartment, in a way that captures a greater breadth of motivating use cases. I would not expect a fresh batch of intrinsics without Realm in the name, as in ShadowRealm.

[ljharb]

It seems very confusing to have it on its own without the motivating use case, ie Compartments.

[naugtur]

We do list Principle of Least Authority in the motivating usecases, which is the wider scope of Compartments.
@ljharb Would it be helpful to say Compartments more explicitly? Does the recent change to slides saying this is the minimum addition to EcmaScript that would allow implementing Compartments in user code helpful?

[ljharb]

I'll have to wait for the presentation, I guess - perhaps it's just the name that doesn't make sense to me.