invariant: strict equality is never side-effecting

[Kevin Gibbons]

If evaluating a and b independently has no side effects, then evaluating a === b doesn't either.

Probably we should list some other definitely-not-side-effecting things which people should be able to rely on.

[yulia]

This makes sense to me but I can't think of a comprehensive motivation. my guess is we want to avoid surprising behavior during strict equality operations. It feels like there may be more reasons beyond this though. It may in fact be this simple but I have a nagging feeling that there is more reason behind this?

[Kevin Gibbons]

My motivation is that this is something people rely on very broadly when reasoning about code (including automatically, i.e. in static analysis).

[Andrew-Cottrell]

I think this is well motivated as I was extremely surprised when this invariant was violated by Internet Explorer 9, in which the following throws "Class doesn't support Automation"

var localStorage = window.localStorage;
Object.defineProperty(window, "localStorage", {get: hookLocalStorage, configurable: true, enumerable: true}); // may silently fail
var hooked = !(window["localStorage"] === localStorage); // IE 9 throws "Class doesn't support Automation"

Documenting this invariant may help prevent violations from occurring in future implementations of JavaScript APIs and Web APIs.

[yulia]

Ok, I will update the motivation to be related to the following: principle of least surprise, a simplified mental model, enabling static analysis.