Support "&&=" and "||=" operators

[munificent]

Dart defines the following "regular" binary operators *, /, %, ~/, +, -, <<, >>, >=, >, <=, <, ==, &, ˆ, |. By "regular", I mean that they do no short-circuiting and are just syntactic sugar for a regular method call. These can all be implemented by user-defined classes.

It also defines three short-circuiting binary operators ||, &&, and ??. These cannot be overridden and do not desugar to method calls.

The regular operators also have self-assignment forms (except for the comparison operators), +=, -=, etc. It used to be the case that none of the short-circuiting operators did. However, when ?? was added, ??= was too. Given that, there is no good reason to omit ||= and &&=. They are consistent with ??= and—more importantly!—are sometimes useful.

So, to harmonize this, we intend to add ||= and &&= to Dart.

Syntax

We add &&= and ||= to compoundAssignmentOperator in the grammar.

Semantics

The semantics are pretty straightforward. The general vibe is that evaluation is "maximally lazy". A subexpression is evaluated at most once, and only if its result is needed.

To describe the desugaring, we need something akin to a "template language". It's basically Dart syntax, with a couple of extra bits:

• C is any identifier that resolves to a type name.
• A name starting with e is a placeholder for an arbitrary expression (except for a typename). It gets inserted as-is in the result.
• name can be any identifier and is substituted as-is.
• bool_convert() invokes the "boolean conversion" procedure in the language spec.

&&=

// An expression like `name &&= e3` desugars to:
(() {
  if (!name) return false;
  return name = bool_convert(e3); 
})()

// An expression like `C.name &&= e3` desugars to:
(() {
  if (!C.name) return false;
  return C.name = bool_convert(e3); 
})()

// An expression like `e1.name &&= e3` desugars to:
(() {
  var x = e1; // Don't double evaluate e1.
  if (!x.name) return false;
  return x.name = bool_convert(e3);
}())

// An expression like `e1?.name &&= e3` desugars to:
(() {
  var x = e1; // Don't double evaluate e1.
  if (x == null) return null;
  if (!x.name) return false;
  return x.name = bool_convert(e3);
}())

// An expression like `e1[e2] &&= e3` desugars to:
(() {
  var x = e1, y = e2; // Don't double evaluate e1 and e2.
  if (!x[y]) return false;
  return x[y] = bool_convert(e3);
}())

||=

// An expression like `name ||= e3` desugars to:
(() {
  if (name) return true;
  return name = bool_convert(e3); 
})()

// An expression like `C.name ||= e3` desugars to:
(() {
  if (C.name) return true;
  return C.name = bool_convert(e3); 
})()

// An expression like `e1.name ||= e3` desugars to:
(() {
  var x = e1; // Don't double evaluate e1.
  if (x.name) return true;
  return x.name = bool_convert(e3);
}())

// An expression like `e1?.name ||= e3` desugars to:
(() {
  var x = e1; // Don't double evaluate e1.
  if (x == null) return null;
  if (x.name) return true;
  return x.name = bool_convert(e3);
}())

// An expression like `e1[e2] ||= e3` desugars to:
(() {
  var x = e1, y = e2; // Don't double evaluate e1 and e2.
  if (x[y]) return true;
  return x[y] = bool_convert(e3);
}())

This desugaring has one wrinkle. It doesn't handle cases where the surrounding code is async or a generator since the function literals don't correctly propagate the "async-ness" or "generator-ness". Instead of actual functions, imagine them to be "block expressions" that let you define variables scoped to the expression instead of actually declaring a function, and you'll have the right idea.

Flag

While this is being implemented, to ensure we don't expose users to inconsistency in our tools, it should be put behind a flag named logical-self-assign.

Tracking issues

• Analyzer (Analyzer: Support "&&=" and "||=" operators #26997)
• dart2js (dart2js: Support "&&=" and "||=" operators #26998)
• dev_compiler(Support "&&=" and "||=" operators dart-archive/dev_compiler#617)
• Formatter (Support formatting "&&=" and "||=" dart_style#515)
• Specification (#26999)
• VM (VM: Support "&&=" and "||=" operators #27000)
• IntelliJ-plugin (IntelliJ plug-in: Support "&&=" and "||=" operators #27091)

[scheglov]

In "An expression likee1[e2] &&= e3desugars to:" and "An expression likee1[e2] ||= e3desugars to:" it seems that e2 is evaluated twice.

[munificent]

Oops, fixed!

[jmesserly]

do we want a DDC bug too? if so it's here: dart-archive/dev_compiler#617

[a14n]

The desugar of e1?.name &&= e3 and e1?.name ||= e3 looks strange to me. Shouldn't it be :

// An expression like `e1?.name &&= e3` desugars to:
(() {
  var x = e1;
  if (x == null) return null;
  var y = x.name;
  if (!y) return y;
  return x.name = e3;
}())

// An expression like `e1?.name ||= e3` desugars to:
(() {
  var x = e1;
  if (x == null) return null;
  var y = x.name;
  if (y) return y;
  return x.name = e3;
}())

[a14n]

I also notice that if e1 = null and e3 = true then e1 = e1 && e3 leads to e1 equals to false but e1 &&= e3 leads to e1 equals to null. Is it intended ?

[munificent]

do we want a DDC bug too? if so it's here: dart-archive/dev_compiler#617

Yes, added it to the list, thanks!

Is it intended ?

Oof, no. Thought it through better and updated the above. This will teach me to put out a proposal before I write tests. :)

[lrhn]

I would also expect the rules for &&= to be:

// An expression like `v &&= e3` desugars to:
(() {
  var x = v;
  if (x) return true;
  return v = boolean_conversion(e3); 
})()

// An expression like `e1.name &&= e3` where `e1` is not a type name, desugars to:
(() {
  var x = e1;
  var y = x.name;
  if (y) return true;
  return x.name = boolean_conversion(e3);
}())

// An expression like `e1?.name &&= e3` desugars to:
(() {
  var x = e1;
  if (x == null) return null;
  var y = x.name;
  if (y) return true;
  return x.name = boolean_conversion(e3);
}())

// An expression like `e1[e2] &&= e3` desugars to:
(() {
  var x = e1;
  var y = e2;
  var z = x[y];
  if (z) return true;
  return x[y] = boolean_conversion(e3);
}())

and similar for ||=.
The boolean_conversion function refers to boolean conversion (16.4.1) in the spec, but there isn't currently a syntax for performing that in code.

We also need a specail case for C.name &&= e3 where C is a type name. Otherwise the operation can't be used on static variables because the e1.name case evaluates e1 to a Type object.

(As usual, the rewrite using an applied function expression isn't sound (#25858), but it's consistent with the other unsound rewrites in the spec).

[jmesserly]

The boolean_conversion function refers to boolean conversion (16.4.1) in the spec, but there isn't currently a syntax for performing that in code.

you could write x ? x : x ... although that's a bit of a hacky way to express it :)

[munificent]

The boolean_conversion function refers to boolean conversion (16.4.1) in the spec, but there isn't currently a syntax for performing that in code.

Ah, right. I didn't realize && and || return the boolean conversion of the RHS. Changed the desugaring to use && and || which I think addresses this.

We also need a special case for C.name &&= e3 where C is a type name.

Done.

[eernstg]

We do have a bunch of ways to say this, I think we're just converging on the level of obscurity of presentation that we are ready to accept. See this gist for some variants of the semantic specification. A tricky point is, for instance, how many times can we call the relevant getter and setter? If we wish to fix that to "call the getter exactly once" and "call the setter at most once, and do not call it in the case that corresponds to shortcut evaluation of the underlying operator && and ||" then the presentation gets a bit less readable.

[eernstg]

PS: x ? x : x evaluates to the value of x, not the boolean-converted value. ;-)

[jmesserly]

PS: x ? x : x evaluates to the value of x, not the boolean-converted value. ;-)

(haha, oops. In my head I've already moved on to strong mode/dart2 where a "bool" is actually true, false, or null, so I was just trying to get the cast+assert-non-null ... yeah, in Dart 1 you'd need x ? true : false to get both the assert(x != null) and the identical(x, true) part... anyway, I'll stop sidetracking this bug with my silly comments :) )

[lrhn]

One shorthand that could work is, say for v.name &&= e:

  (v.name && (v.name = boolean_convert(e)))

You still need the temporary variables when the LHS isn't simple, like e1[e2] &&= e3:

  (x = e1)[y = e2] && x[y] = boolean_convert(e3)

(where x and y are fresh variables and boolean_convert might just be !!).

[fsc8000]

Why not just have the following rule:

e1 op= e2 is equivalent to e1 = e1 op e2 except that e1 is only evaluated once.

I think this is true for all existing compound assignment operators.

[munificent]

except that e1 is only evaluated once.

That's more or less what the proposal specifies. It's just that saying "e1 is only evaluated once" doesn't precisely capture that fact that it appears in both lvalue and rvalue position and the distinctions between the two.

[lrhn]

You will never get x ? true : false through a code review with me 😈
Alternatives are x == true which doesn't throw in checked mode, or !!x which does.

That latter is idiomatic in JavaScript, but Dart has rarely needed it because most programs are checked-mode correct, so non-boolean values almost never end up in a boolean situation anyway.

This specification has to account for it since it is defining a new boolean context, but everybody else should generally just not worry.

[lrhn]

The reason for lhs &&= rhs not being equivalent to lhs = lhs && rhs is that it's unnecessary to do the assignment when the short-circuit operator bails out. In that case, it will be equivalent to lhs = lhs, and then it's easier to just not do the assignment.
We did the same thing for ??= - if the left-hand operand is null, we don't assign null back to it again.

It gets slightly more complicated because unchecked mode can allow a non-bool left operand to evaluate to false, so lhs = lhs && rhs is bailing out but actually assigning a different (now bool) value back.
Still, the program is bad and the author should feel bad. It would throw in checked mode, and I'm not particularly worried about not assigning a boolean back to the variable in this case.

[eernstg]

Executing the setter in the case where shortcutting is supposed to occur could have arbitrary side-effects, so it does matter.

[fsc8000]

Correct @eernstg . The question is if the assignment is executed or not. I think it is important that the programmer, who refactors code from E1 = E1 op E2 into E1 op= E2 does not get caught by surprise, because this refactoring is a breaking change for the short-circuit operators?

@lrhn If the assignment boils down to assigning back the value itself (i.e. the setter is a simple assignment), the compiler would figure this out and not perform the store. - If it does not do this right now, it would be easy to make sure it does.

I would rather change ??= to be consistent with the rule I proposed than adding these new operators with surprising semantics.

[munificent]

because this refactoring is a breaking change for the short-circuit operators?

It's potentially a breaking change but is rarely one in practice.

the compiler would figure this out and not perform the store

That's hard to do in the general case since setters can have arbitrary side effects.

I would rather change ??= to be consistent with the rule I proposed than adding these new operators with surprising semantics.

That would be a breaking change to the language.

I don't personally have a strong opinion here (in fact, I don't personally care about this feature at all), I just tried to come up with semantics that are consistent with ??= and had a coherent principle behind it.

The other logical operators seem to have a rule of being "maximally lazy"—they only evaluate a subexpression if needed, so I did the same thing here.

[srawlins]

Most of the "Tracking issues" have been closed as "Will implement in CFE". I don't know if there is an issue for CFE because GitHub search does not like &&= or ||=...

[jmesserly]

Most of the "Tracking issues" have been closed as "Will implement in CFE". I don't know if there is an issue for CFE because GitHub search does not like &&= or ||=...

it looks like it is at least partially implemented, but disabled in CFE (LAZY_ASSIGNMENT_ENABLED). I wasn't able to find any open CFE bugs tracking this. I don't know whether it is implemented beyond parsing.

Analyzer has some support as well, and is also disabled (scanLazyAssignmentOperators).

[vsmenon]

Closing this in favor of dart-lang/language#23