Short-circuiting concerns

[ljharb]

(raised by @bakkot in the meeting today)

Currently, every assignment combo operator in JS can be described as a = a <op> b being equivalent to a <op>= b.

Including the short-circuiting semantics would make a = a <op> b equivalent to if (a) { a = a <op> b; }, which is a very large inconsistency.

The argument that "Ruby and CoffeeScript have these semantics" imo does not hold its weight compared to "it would be inconsistent with the rest of JS".

[bakkot]

The pedant in me is compelled to note that in cases where evaluating the LHS is observable the sugar is a little more complicated because you need to avoid triggering the side effects multiple times (though most implementations get it wrong, and do in fact trigger a subset of the side effects several times). No one should care about this, though.

[jridgewell]

Ruby and CoffeeScript have these semantics

On this, both Ruby and CoffeeScript have mathematical operators that always assign, and logical operators that short-circuit assign.

it would be inconsistent with the rest of JS

Meaning the mathematical assignment operators? but none of them could ever have short circuiting semantics.

I think the better argument for always-set semantics path is that it's closer to (my personal intuition) the common de-sugared form (a = a || b). But, I'm pretty sure this is the common because the short-circuit-set semantics is usually a lint error (useless expression).

But, I'm open to either semantics.

where evaluating the LHS is observable the sugar is a little more complicated because you need to avoid triggering the side effects multiple times

This is separate from short-circuiting semantics, but I intend for this to follow whatever the rest of the spec uses, which I hope accounts for deep properties and computed keys.

obj.a.b ||= 'test';
(_a = obj.a).b || (_a.b = 'test');

obj.a[key++] ||= 'test';
(_a = obj.a)[_key = key++] || (_a[_key] = 'test');

[hilbix]

Sorry to comment here late and long. But I am not so familiar with the background of the JS spec and who is allowed to express thoughts here. And please forgive if this is a FAQ, I do not know where and how to look for such.

However I'd always vote for the most performant way to implement things if this does not break mathematical correctness. This also means, to allow engines to skip calls to setters if those calls look invariant (which might not necessarily be procedurally correct then) to the value.

So my idea is to turn it around and allow shortcuts like in the ||= case to be allowed in the += case, too!

a += b is internally done by somethings like var _=a; _=_+b; a=_ so I'd vote that engines are allowed to optimize that to

var _ = a
_ = _ + b
if (_ !== a) a = _    // optionally spare the if() and do a = _ here

which skips calls to the setter if nothing changes. (Note that this should not be imperative, because there will be many cases where calling the setter is more performant than implementing the identity check. And I am talking about performance here.). Now a ||= b flies just the same route:

var _ = a
_ = _ || b;
if (_ !== a) a = _

which effectively is

if (!a) a = b;

To keep the idea that a = a <op> b should be the expanded form of a <op>= b, this means, that it should be allowed to skip the assignment (=setter) if the (known) value is unchanged.

The motivation behind this is that setters should do the obvious thing. Storing the same value multiple times or only store it a single time should not catastrophically change things from a stability point of view. (Also getters should never return a value different from what setter expect to set the value returned by the getter again.) On JS this might break some constructs of Observables, which use such a bad approach to enforce some UI updates/refreshes. However for this a clear call to something like a.refresh() or a.refresh++ or a.refresh_trigger = !a.refresh_trigger should be a far superior approach, as this creates clear and concise code which everybody can understand out of the box.

Note:

• I am not into JS spec, so perhaps this is a fundamental change in some principles there. But a good language should be allowed to optimize for performance (as long as this does not break some very imperative other things which cannot be expressed otherwise). And adding some internal assumptions on how getters/setters should be implemented, is not a bad thing.

• Statically compiled languages like C are not a good choice to compare here. The C++ compiler has a good way to examine (inline) the getters/setters at compile time and optimize that. However JS is an interpreted language where everything can change on runtime, so it shall have other ways of optimization, possibly sacrificing some constraints on how side-effects must be handled in-detail, especially if those side-effects are not obvious to the common programmer anyway and hinder performance and generalization a lot.

• Also the C++-optimization is, strictly speaking, not free from side-effects, as at assembly level the "add"-instruction is optimized away which can change behavior of a program. This could make differences on things like Spectre and the like. Hence there always is some tradeoff between speed and compliance, where I always go for speed, as long as the pure mathematical result stays correct.

Compare:

• Spectre is not a bug from my perspective, it's just a side-effect of a speed feature which only has some possibly bad side-effects in certain few and from my perspective very negligible situations. So yes, Spectre has an impact on Cloud setups, but you always needed to be aware of side-channels on things like this, so you had to harden your code. This already was true in the last millennium with non-speculating processors (you were able to measure the power consumption to detect things you are not supposed to access, and there were even exploits known using sound cards to record things like password keystrokes). This is comparable to the shortcut taken here. Yes, it might break some existing code. But only bad code which relies on side-effects, which are not obvious to everybody, and this creates very hard do maintain code and should be changed anyway.

• In contrast, Meltdown and SWAPGS are bugs, because both have a vast impact on kernel security guarantees. But I cannot see any similar bad thing happen here if you allow shortcuts for += as expressed above. The vast majority of sane code should continue to work completely unharmed, regardless of minified or not.

[ExE-Boss]

But what if I want to have:

let hasErrors = testForSomeErrors(foo, logger);
hasErrors = testForOtherErrors(foo, logger) || hasErrors;

So that testForOtherErrors() is also executed, even if testForSomeErrors() already detected some errors, so that the other errors are also logged.

[claudepache]

But I am not so familiar with the background of the JS spec

@hilbix For information, the current state of the spec is: Implementations are allowed to do any optimisation provided that it does not change the observable behaviour, which is probably much more restrictive than what you want. Number of wasted CPU cycles does not count as observable; but observable side-effects not related to time and memory do count.

If you want to allow implementations to do more optimisations, that might change the observable behaviour in edge cases, this is not the place to propose it, because it is a major change in the language semantics. See https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#new-feature-proposals for places where you can express your ideas (the es-discuss mailing list is one place to discuss them). (Although I am personally sceptical that this particular idea will fly , because the tendency is to reduce observable variations between implementations.)

[claudepache]

I disagree with this argument:

Currently, every assignment combo operator in JS can be described as a = a <op> b being equivalent to a <op>= b.

Including the short-circuiting semantics would make a = a <op> b equivalent to if (a) { a = a <op> b; }, which is a very large inconsistency.

for the simple reason that descriptions like “a = a <op> b is equivalent to a <op>= b” are willingly incorrect for the sake of simplicity. You already know that you must add: “(except that, of course, a is not evaluated twice)”; now you just need to add: “(and except that, of course, in case of short-circuiting, the value just read in a is not re-written in a)”; there is no need to resort to some alternative (incorrect) expansion such as if (a) { a = a <op> b; }.

In fact, if we look at real semantics instead of simplistic expansions, there is absolute consistency. Here is a synoptic view of the differences of semantics between a + b, a += b, a || b and a ||= b:

<OP>	a <OP> b	a <OP>= b
non short-circuiting operator (e.g., +)		assign the final result to a
short-circuiting operator (e.g., ||)	possibly skip the rest of the algorithm (short-circuit)	possibly skip the rest of the algorithm (short-circuit) assign the final result to a

The question is whether the “assign the final result to a” step is part of the algorithm that is possibly short-circuited. I say: yes, of course, because the goal of short-circuiting is precisely to avoid operations that are useless in “regular” cases (i.e., assuming that evaluating subexpressions does not trigger observable side-effects, assuming that re-writing the same value just read in some binding is a no-op, and other whatnots)

Concretely, the only case where the difference is observable, is when assignment does something weird or perform some non-trivial work. E.g.

previewElement.innerHTML ||= '<i>Nothing to show</i>'

In that specific case—and I expect in most cases—you most probably don’t want to trigger the .innerHTML setter, as it could have unwanted side-effects (such as the user losing the focus in case it was on some child element of previewElement). If, for some obscure reason, you do want to always trigger the .innerHTML setter, you’d better be more explicit.

[jridgewell]

@claudepache The el.innerHTML ||= 'default' is a great example. Want to add it to the readme?

[hax]

"a = a <op> b being equivalent to a <op>= b" may be too simple, but I feel it reflect the mental model of most programmers.

The problem is, when programmers see a ||= b, will they consider short-circuiting semantic first?

If, for some obscure reason, you do want to always trigger the .innerHTML setter, you’d better be more explicit.

We could also say, if you do not want to trigger the setter, you'd better be more explicit --- write if (el.innerHTML) el.innerHTML = ....

In which direction more explicit is better choice? I don't know.

Some programmers think <op>= as a shorthand, and the doc of ESLint operator-assignment rule said:

Use of operator assignment shorthand is a stylistic choice. Leaving this rule turned off would allow developers to choose which style is more readable on a case-by-case basis.

Whichever we choose, it's not a stylistic choice anymore.

So the most conservative teams might even choose enforcing explicit for both directions, aka. disallow logical assignment operators (via eslint).

Note, actually I will choose current short-circuiting semantic if I'm forced to choose one. Just feel it's really an issue if the feature is added while a lint rule is also added to forbid it 🤓

[Mouvedia]

Whichever we choose, it's not a stylistic choice anymore.

So the most conservative teams might even choose enforcing explicit for both directions, aka. disallow logical assignment operators (via eslint).

This.

[claudepache]

Some programmers think <op>= as a shorthand, and the doc of ESLint operator-assignment rule said:

Use of operator assignment shorthand is a stylistic choice. Leaving this rule turned off would allow developers to choose which style is more readable on a case-by-case basis.

Whichever we choose, it's not a stylistic choice anymore.

The doc of ESLint can continue to lie, and say that a ||= b is equivalent to a = a || b. In most cases, skipping a = a makes zero differences. In few cases, it makes a small difference, but it is sufficiently subtle for most coders not to care.

In rare cases it makes a noticeable difference, and:

• even in those cases, skipping the self-assignment is probably the most secure choice;
• programmers that do care of the difference will also care to understand correctly the code.

[ExE-Boss]

• programmers that do care of the difference will also care to understand correctly the code.

I’ve seen far too much horrible, buggy code in my life that this sadly feels very unlikely to me.

[hilbix]

If a language is created for programmers who do not care, then the language will not take care of the programmers who do care.

[jridgewell]

Closing this, as I feel #3 (comment) answers everything.