require parentheses sometimes to disambiguate confusing operator precedence

[PavelVozenilek]

Look at the cryptic table:

x() x[] x.y
!x -x ~x *x &x ?x %x %%x
x{}
* / %
+ - ++
<< >>
&
^
|
== != < > <= >=
&&
||
?? %%
= *= /= %= += -= <<= >>= &= ^= |= &&= ||=

Why it is all needed? Who will find the time to learn it? I had not internalized C precedence after two decades.

Language Pony does it differently:

Pony takes a different approach and outlaws infix precedence. Any expression where more than one infix operator is used must use parentheses to remove the ambiguity. If you fail to do this the compiler will complain.

[andrewrk]

Interesting idea. This is on the table since it adheres to the principle that being readable is more important than being writable.

Arguments against it are that it would be strange and cumbersome for people coming from a C background. People are used to 3 * 4 + 1 meaning that the multiplication comes first.

[emanuelpalm]

👍

[andrewrk]

Some precedence is necessary, such as assignment, function call invocation, array index. Too much parens and the language turns into lisp.

[PavelVozenilek]

Assignment, function call, array index are not infix operators. Could there be any ambiguity with them?

I can imagine having default precedence for basic arithmetic (+-/*), this is what little kids get drilled in schools, but IMO it is not worth the effort. One never writes 3 * 4 + 1 in the code, one does some_variable * another_variable + something_completely_else, and all advantages of short infix syntax get lost there anyway. Brackets would help to separate it into visual chunks.

[PavelVozenilek]

Also, this feature would make adding user defined operators into the language easier.

[thejoshwolfe]

I think this would be a cool idea for some categories of operators, specifically the ones i can never remember the precedence for. e.g. a && b || c would be a compile error, or a & b | c. i don't think we need to go so far as to outlaw a + b * c though.

[thejoshwolfe]

see also #29

[phase]

My favorite quote from the Pony page is

Most people will remember to do multiplication before addition, but what about left bit shifting versus bitwise and? Sometimes people misremember (or guess wrong) and that leads to bugs. Worse, those bugs are often very hard to spot.

I love the idea for specific parens. It makes the execution crystal clear.

[thejoshwolfe]

The current operator precedence table is inspired by C. But I think Zig can do better than that. For example, & > ^ > | seems pretty silly. Even if you think & > | makes sense (because of the analogy to * and +), it's still pretty confusing that ^ is in the middle of them.

I wanted to write up a proposal here to outline a new precedence table for operators in Zig, but Zig's grammar is a bit more complicated than the current table in doc/langref.md shows, and it's not as simple as rearranging and combining some rows.

At the very least, I'd like to see required parentheses for: &, ^, |, <<, >> intermixed with each other, and for and and or intermixed with each other. There's more to the proposal, but I need to do a more careful analysis of Zig's grammar before posting something comprehensive.

[thejoshwolfe]

Here's the real story on Zig's expression grammar (this does not include grammars such as statements, case declarations, top level declarations, etc.). I'll write a follow up comment documenting what i think the expression grammar should be changed to.

There are three types of operator:

• infix operators: always start with x and end with y, where x and y are some expressions
• prefix operators: always end with x, where x is some expression
• suffix operators: always start with x, where x is some expression
• primary expressions: not really operators, because they are either a single token, or they start and end with unambiguous grouping tokens.

A chainable operator is one that you can use like a + b + c, !!x, or a(b)(c), and has a well-defined associativity. All infix chainable operators are left-to-right associative (e.g. a - b - c == (a - b) - c). Chainable prefix and suffix operators have an obvious associativity (right-to-left and left-to-right respectively). A not-chainable operator cannot be used repeatedly, e.g. inline inline a, a{}{}, and a = b = c are all not allowed.

The following is a list of operator groups. The groups are listed here in order of highest-to-lowest precedence. Each item in a group has equal precedence. If a group is chainable, the operators in the group can be intermixed while chaining (e.g. a.b[c]).

primary expressions:

• 123 - and variations, where 123 is a number literal
• "..." - where ... is the characters of the string literal
• '...' - where ... is the characters of the char literal
• true, false, null, continue, undefined, error, this, unreachable
• id - where id is an identifier
• @id(...) - where id is an identifier and ... is a parameter list
• goto label - where label is a label
• break, return - without an expression
• (x)
• {...} - where ... is a statement list
• asm ("...") - and variations, where ... is inline assembly
• struct { ... } - and variations, where ... is a container member list
• if (a) {...} - and variations, where ... is a statement list[1]
• if (a) b else {...} - and variations, where ... is a statement list[1]
• while (a) {...} - and variations, where ... is a statement list[1]
• while (a) b else {...} - and variations, where ... is a statement list[1]
• for (a) {...} - and variations, where ... is a statement list[1]
• for (a) b else {...} - and variations, where ... is a statement list
• switch (a) {...} - where ... is a case list
• comptime {...} - where ... is a statement list[1]

prefix, not chainable:

• inline x

suffix, chainable:

• x(...) - where ... is a parameter list
• x[a] - and variations
• x.id - where id is an identifier

prefix, chainable:

• !x
• -x, -%x
• ~x
• *x
• &x - and variations
• ??x
• %%x
• ?x
• %x
• []x - and variations
• extern fn() -> x - and variations

suffix, not chainable:

• x{...} - where ... is a container init body

infix, chainable:

• x * y, x *% y
• x / y
• x % y
• x ** y

infix, chainable:

• x + y, x +% y
• x - y, x -% y
• x ++ y

infix, chainable:

• x << y, x <<% y
• x >> y

infix, chainable:

• x & y

infix, chainable:

• x ^ y

infix, chainable:

• x | y

infix, not chainable:

• x == y - and variations
• x < y - and variations

infix, chainable:

• x and y

infix, chainable:

• x or y

infix, chainable:

• x ?? y
• x %% y - and variations

infix, not chainable:

• x = y - and variations

prefix, chainable:

• return x
• break x
• if (a) x - and variations[1]
• if (a) b else x - and variations[1]
• while (a) x - and variations[1]
• while (a) b else x - and variations[1]
• for (a) x - and variations[1]
• for (a) b else x - and variations[1]
• comptime x[1]

[1]: for the statement-like expressions if, for, while, and comptime, a special exception is made that if a body expression starts with a block (starts with a {), then the body expression ends at the end of that block (at the }). This disallows, for example, if (a) {b} + 1 else {c}.