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.
Is
3 << 5 - 1parsed as(3 << 5) - 1or3 << (5 - 1)? C++ and Go give different answers!Similarly,
6 & 2 == 2is6 & (2 == 2)in C++ but(6 & 2) == 2in Go. These reduce to6 & 1for C++ and2 == 2for Go, which are obviously different (0andtrue).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:
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)*orconst (T*)? In cppfront,* const Tis unambiguous, reading left-to-right.The concrete suggestion: mandate parentheses when combining multiple binary operators. The programmer has to explicitly write either
(3 << 5) - 1or3 << (5 - 1). A bare3 << 5 - 1would be a compiler error.