[SUGGESTION] eliminate operator precedence (and require parens)

[nigeltao]

Is 3 << 5 - 1 parsed as (3 << 5) - 1 or 3 << (5 - 1)? C++ and Go give different answers!

#include <iostream>

int main() {  // Prints 48, which is "3 << (5 - 1)".
  int x = 3 << 5 - 1;
  std::cout << x << std::endl;
  return 0;
}

package main

import "fmt"

func main() {  // Prints 95, which is "(3 << 5) - 1".
	x := 3 << 5 - 1
	fmt.Println(x)
}

---

Similarly, 6 & 2 == 2 is 6 & (2 == 2) in C++ but (6 & 2) == 2 in Go. These reduce to 6 & 1 for C++ and 2 == 2 for Go, which are obviously different (0 and true).

For reference: C++ Operator Precedence and Go Operator Precedence

Like any curly-bracket language, Go looks a lot like C++, but copy/pasting a Go snippet from stackoverflow.com into a C++ program might have subtly different semantics.

---

I acknowledge that the SUGGESTION template says:

Please do not suggest syntax changes. I accept there are hundreds of opinions and everyone will prefer something a little different.

However, it also says "Please limit suggestions to quantifiable improvements to C++ simplicity, safety, or toolability" and there is a safety angle here. Operator precedence ambiguity has been a source of bugs in parsers. For example, in a library that emphasizes safety: jbangert/nail#7

Simplifying (by eliminating the idea of and need for precedence) is also similar to simplifying C++'s const T* type syntax. In C++, is it (const T)* or const (T*)? In cppfront, * const T is unambiguous, reading left-to-right.

---

The concrete suggestion: mandate parentheses when combining multiple binary operators. The programmer has to explicitly write either (3 << 5) - 1 or 3 << (5 - 1). A bare 3 << 5 - 1 would be a compiler error.

[JohelEGP]

I recall that Rust,
and I think most definitely Carbon,
distinguish that not all operators are made equal.

They divide them into arithmetic ones, bit-wise ones, and so on.
I do not know what they do with this information, however.

We can have a similar classification,
and require parentheses where it makes sense.
At the very least, I do not think the arithmetic ones need mandated parentheses.

[AbhinavK00]

Carbon uses some kind of partial precedence to determine order of operators. Here.
Cppfront could have something similar but maybe we can do better.

[JohelEGP]

Here's an example by Sean Baxter from "Circle Evolves C++ | Sean Baxter | NYC++": https://youtu.be/P1ZDOGDMNLM?t=901.
It's the same as the recently added

cppfront/include/cpp2util.h

Line 1623 in ecd3726

return [=](strict_value<T, Tag, true> value) { return (value & flags) == flags; };

See also https://youtu.be/P1ZDOGDMNLM?t=1926.

[nigeltao]

IIUC "Circle Evolves C++" uses Carbon's precedences (after a #feature opt-in), but while Carbon's precedence might be "better defaults" than C++, the Carbon's precedence diagram in @AbhinavK00's and @JohelEGP's links still contains 30 nodes and 40 edges (roughly, I lost count).

In comparison, "mandate parentheses when combining multiple binary operators" is a single, short sentence. To me, this seems
closer to cpp2's "reduce the guidance we have to teach by B%" goal.

[nigeltao]

Another point against "just re-organize the precedence table" is that a .cpp2 file can mix C++1 and C++2 code. It'd be weird if, for a line of code like return value & flags == flags;, copy/pasting it elsewhere within the same file changed its meaning (but without any compiler error or even compiler warning).

In contrast, with mandatory parens:

• when copy/pasting from C++2 to C++1, the parens might now become unnecessary but the expression still parses the same.
• when copy/pasting from C++1 to C++2, it's a noisy compiler error, which seems preferable to a silent subtle-change-in-behavior.

It doesn't even have to be copy/paste. cpp2 aims to support gradual migration. You can start with your foo function in C++1 and you should be able to re-write it in-place as C++2. "Re-write it in-place" might involve leaving some lines untouched and, again, it seems dangerous if that could produce subtle bugs.

[AbhinavK00]

I think I agree with you here. Taking the conservative approach also allows for changes in the future becaude any code with use of parens will never become illegal. On the other hand, if we determine the precedence now and realise that it needs changes, existing code will have to be modified.

[jcanizales]

In comparison, "mandate parentheses when combining multiple binary operators" is a single, short sentence. To me, this seems
closer to cpp2's "reduce the guidance we have to teach by B%" goal.

This is true in a vacuum. But in our actual culture you would have to explain to everyone why m * x + b fails to compile: Because cpp2 doesn't know the precedence of mathematical operators, like everyone that's gone through elementary school does.

About the other operators I agree. They're made up anyway, so no need to make up precedence rules that no one bothers memorizing because they're made up.

[nigeltao]

have to explain to everyone why m * x + b fails to compile

Programming isn't math. We already have to explain why x = x + 1 is a perfectly good program statement even though it's bonkers in math. We also have to explain that x < (x + 1) isn't always true (because of overflow, let alone Undefined Behavior), and neither is x == x (because of floating point NaNs).

[JohelEGP]

The domain of operations is a different matter from precedence.
x < (x + 1) in particular is OK to not always be true for modulo arithmetic integer types such as unsigned
(see the last sentence of the "Note 1 to entry" of IEV 102-01-11).

[jcanizales]

I don't to see the logic in "because we already have to explain these gotchas, we should annoy everyone that wants to write simple arithmetic expressions the way all humans do".

In particular I don't see how it addresses my point at all. My point was:

you would have to explain to everyone

Which is contrary to the goals of this project (explaining less, not more).

[AbhinavK00]

you would have to explain to everyone

It would be easier to explain though, you just say that "cpp2 doesn't know this (yet)" but explaining operator precedence is harder like is the case with cpp.

[nigeltao]

you would have to explain to everyone why m * x + b fails to compile... like everyone that's gone through elementary school [is familiar with].

Well, we already have to explain why y = m x + b fails to compile (because, in programming, m x doesn't implicitly mean multiplication), even though that's idiomatic math syntax.

In particular I don't see how it addresses my point at all

My point is that we have to explain something anyway. Math syntax is already different from programming syntax. We're just debating whether it's different by this much or that much, and the difference is small.

For math syntax, ambiguity isn't that problematic. A human reader can usually guess which interpretation is the 'obvious' one. Or they learn inconsistent (but convenient) idiosyncracies like sin ² x doesn't mean sin(sin(x)) or sin(x²) but actually means (sin(x))².

For programming syntax, there are benefits to being unambiguous and consistent, especially if software bugs can lead to security vulnerabilities.

[ntrel]

Is 3 << 5 - 1 parsed as (3 << 5) - 1 or 3 << (5 - 1)? C++ and Go give different answers!

Seeing as shifts are merely multiplication/division by power of 2, there's a mathematical argument that C++'s precedence is more correct than Go's. D also does this.

Similarly, 6 & 2 == 2 is 6 & (2 == 2) in C++ but (6 & 2) == 2 in Go

D's reference compiler requires parentheses for any equality/relational operation where one side is an &, | or ^ operator expression. Also when the 'else' branch of a conditional expression is a relational operator:

t ? a = 1 : b = 2  // error
(t ? a = 1 : b) = 2
t ? a = 1 : (b = 2)

More generally I suggest making implicit bool to integer conversion not work in an expression, to prevent bugs.

Edit: Fixed last line of conditional.

[TheHiddenStep]

I personally always used parentheses for the bitwise operators, because

• they are almost always needed to do the thing I want to express.
• code readability comes first. If I have to think about operator precedence issues then I already wasted precious brain cycles for something very low level.

The bad operator precedence comes from the early K&R days and it should have been fixed then, but wasn't. As others mentioned before fixing it in cppfront is not really an option because cpp2/cppfront and C++ will coexist.

Partial precedence ordering (used by for example carbon) seems like a fine solution. Force the coder to disambiguate.

[hsutter]

Thanks! I think I've answered this, and addressed it for <<'s interactions with comparisons, in the comment thread starting here:
#817 (comment)

Briefly: It's reasonable for << with its built-in bitwise meaning to be high-precedence, but in the 1990s overuse of overloading was popular, including its use for streaming I/O which inherently wants to be low-precedence but can't change the actual operator's precedence... and that overloaded use of << became popular so we keep having this surprise. In fact, I think << is the poster child for precedence issues, because it's the major case that invented a later use of the operator for something very different, that became very popular.

Operator overloading is fine, but I view << for streaming as a warning example about why we shouldn't overuse the feature, and when we do use it we should closely follow the built-in operators' meanings... as Scott Meyers would say (and did), "do as the ints do."

[nigeltao]

From #817:

For Cpp2, I briefly considered changing << and >> to be lower precedence

Keeping C++'s precedence order is a fine (least-surprising) decision if you're keeping the idea of operator precedence around. And, sure, the 1990s were over-enthusiastic about overloading <<. And the language can't change precedence for user-defined operators.

But "be just like C++" means that the jbangert/nail#7 bug (a bug in C++ code, in a security-concious library, that's using << on ints, not streams) would still be a bug in Cpp2 code. And it's a bug that's not super obvious just from looking at the source code.

OTOH, eliminating the idea of operator precedence eliminates that class of bug, regardless of whether or not overloading << is a good idea.

The earlier "6 & 2 == 2 is 6 & (2 == 2) in C++ but (6 & 2) == 2 in Go... copy/pasting a Go snippet from stackoverflow.com into a C++ program might have subtly different semantics" example also has nothing to do with the << operator and isn't affected by using std::format.

[ntrel]

highbyte & 63 << 8

A left shift is a multiplication, so the result is equivalent to highbyte & 63 * pow(2, 8). In that rewrite, it's clearer that the multiplication happens first. So this may be bug prone, but there is a teachable rule to help remember the precedence: that shifts are equivalent to multiplication/division.

[gregmarr]

I tend to use parens whenever there is more than one operator, unless it's basic math, as I don't want to have to remember operator precedence beyond PEMDAS, so I would be fine with requiring parens in the name of safety and security.

[JohelEGP]

I have an use case for abusing ^ that benefits from required parentheses.
I want ^ to mean exponentiation, but its precedence is different from math.
For example, I had some code like
qty::mass * (qty::length ^ -1) * (qty::time ^ -2), that without parentheses
qty::mass * qty::length ^ -1 * qty::time ^ -2 means
(qty::mass * qty::length) ^ (-1 * qty::time) ^ -2, which is ill-formed.
I have to be mindful, because it could also be well-formed and wrong.