Partial Order Precedence
Zig now uses partial operator precedence, so mixing some operators without parentheses is a compile error.
Extract
This page contains a curated list of recent changes to main branch Zig. This page contains entries for the year 2026. Other years are available in the Devlog archive page. October 24, 2026Partial Operator Precedence Author: Ryan LiptakAs of yesterday, the second oldest open proposal for the Zig language was issue #114: require parentheses sometimes to disambiguate confusing operator precedence, opened February 8, 2016. Ten years later, that proposal has been implemented in the master branch version of Zig thanks to contributor CMDRZero.This means that some combinations of operators no longer have a defined precedence, and for those that don’t, the compiler will now require parentheses:const a = x orelse y == z; test.zig:1:22: error: ambiguous operator precedence with operators ... orelse ... == ...; use parentheses to disambiguate const a = x orelse y == z; ^~ test.zig:1:13: note: previous ambiguous operator here const a = x orelse y == z; ^~~~~~ test.zig:1:22: note: in zig 0.17.x, this was evaluated as (... orelse ...) == ... However, common cases can remain parenthesis-free:const a = x + y * z; The idea behind this is to reduce the number of rules a programmer needs to know when reading and writing Zig code. For example, no matter how experienced you are with Zig, it’s unlikely that you’d be able to explain the evaluation order of the following expression without looking up the precedence rules:a & b + c * d >> e | f orelse g() catch h + i == j or k and l With the now-required parentheses added (while maintaining the same evaluation order as the Zig 0.17.x precedence rules), that expression would look like this:((((a & ((b + c * d) >> e)) | f) orelse g()) catch (h + i)) == j or (k and l); Still quite hairy, and not something I’d like to see in the wild, but nonetheless it’s understandable without knowing any precedence rules beyond arithmetic and comparison. Outside of this contrived example, though, the expressions that will now require parentheses are relatively rare (353 lines needed changes out of the million+ lines of code in the Zig codebase).What you need to knowIn practice, going forward, you will only need to remember the rules around operator combinations that still have a defined/unambiguous precedence. For example, when reading or writing code involving arithmetic operators, you’ll only need to remember the following precedence table:* / *% *| %
- +% -% +| -| == != < > <= >= and or You might notice that there isn’t anything too …