Wonky evaluation order for SuperProperty

[jridgewell]

Per the spec:

SuperProperty: super [ Expression ]
  1. Let propertyNameReference be the result of evaluating Expression.
  2. Let propertyNameValue be ? GetValue(propertyNameReference).
  3. Let propertyKey be ? ToPropertyKey(propertyNameValue).
  ...
  5. Return ? MakeSuperPropertyReference(propertyKey, strict).

Runtime Semantics: MakeSuperPropertyReference(propertyKey, strict)
  1. Let env be GetThisEnvironment( ).
  ...
  3. Let actualThis be ? env.GetThisBinding().
  ...

This differs from regular MemberExpression:

MemberExpression: MemberExpression [ Expression ]
  1. Let baseReference be the result of evaluating MemberExpression.
  ...
  3. Let propertyNameReference be the result of evaluating Expression.

The fact that we evaluate the the inner [ Expression ] before evaluating the super feels wrong. I realize super.property isn't really a MemberExpression, but it looks just like it. This is observable with super[super(), "prop"], allowing me to initialize the this binding (GetThisEnvironment ().BindThisValue(...)) even after I've referenced it.

Can we move the env.GetThisBinding() into SuperProperty's RS: Evaluation?

As for real-world implementations of super[super(), "prop"]:

Implemntation	Throws?
Chrome	Yes
Firefox	No
Safari	Yes
Edge	🤷‍♂️ No
Babel	No, but I'm about to change it...

[ljharb]

It’d be good to know what edge does here.

[ljharb]

It’d be good to know what edge does here.

[jridgewell]

I'll try downloading an IE VM. In the meantime, try https://output.jsbin.com/miderik/1/quiet if you already have one.

[jridgewell]

I'll try downloading an IE VM. In the meantime, try https://output.jsbin.com/miderik/1/quiet if you already have one.

[jridgewell]

Whoo, SauceLabs to the rescue. Edge 16 doesn't throw.

[jridgewell]

Whoo, SauceLabs to the rescue. Edge 16 doesn't throw.

[ljharb]

In that case, it's 50/50, so it could go either way for web compat.

How might this change impact future proposals, like decorators or private class methods?

[ljharb]

In that case, it's 50/50, so it could go either way for web compat.

How might this change impact future proposals, like decorators or private class methods?

[allenwb]

I agree, resolving this first would be more consistent with normal left-to-right evaluation order. Since this is only observable in a constructor using unlikely code pattern I don't think there will be any problem with changing it.

[allenwb]

I agree, resolving this first would be more consistent with normal left-to-right evaluation order. Since this is only observable in a constructor using unlikely code pattern I don't think there will be any problem with changing it.

[bakkot]

This is kind of an interesting question. On the one hand, it's inconsistent with member access. On the other, the current behavior is strictly more useful, albeit only in extremely weird cases.

Because of those competing values I don't personally care much either way, though I'd lean towards prioritizing the first (i.e., changing the spec to throw for super[super()]).

[bakkot]

This is kind of an interesting question. On the one hand, it's inconsistent with member access. On the other, the current behavior is strictly more useful, albeit only in extremely weird cases.

Because of those competing values I don't personally care much either way, though I'd lean towards prioritizing the first (i.e., changing the spec to throw for super[super()]).

[gsathya]

As others point out, it does seem very inconsistent to have this[super()] throw, but not super[super()]. +1 for changing the spec to throw.

[gsathya]

As others point out, it does seem very inconsistent to have this[super()] throw, but not super[super()]. +1 for changing the spec to throw.

[allenwb]

+1

[allenwb]

+1