mrkeyoor.com_
Mon 26 Oct 03:07 UTC
Open Source3 min read

Zig master requires parentheses for ambiguous operator precedence

Zig's development branch requires parentheses for ambiguous operator combinations. Its upgrade formatter preserves the previous evaluation order, so developers still need to review the grouping.

Zig's development branch now requires parentheses for operator combinations whose precedence the language leaves undefined. In an October 24, 2026 devlog, Ryan Liptak reported that contributor CMDRZero had implemented the change in master. Developers tracking that branch need to make the grouping explicit and check that it matches their intended behavior.

The announcement concerns master rather than a stable release. The original proposal dates to 2016, when its author questioned how much precedence detail programmers could reasonably remember.

What needs explicit grouping

The devlog demonstrates the new compiler error with this expression fragment:

x orelse y == z

The compiler rejects it as ambiguous. The diagnostic says that Zig 0.17.x evaluated it as (x orelse y) == z: equality applies to the result of the orelse expression. Parentheses now make that grouping explicit.

Common arithmetic remains familiar. The devlog shows x + y * z without parentheses, with multiplication taking precedence over addition. Remainder operations need more care: % still takes precedence over addition and subtraction, but requires parentheses when combined with multiplication, division or another %.

The language reference describes this as partial operator precedence. Some operator combinations have a defined order; ambiguous combinations require parentheses. MrKeyoor has not run a compiler reproduction. The expression and diagnostic above come from the devlog.

Review what the formatter preserves

Liptak gives two migration options: fix the compiler errors manually or use zig fmt --upgrade. The formatter adds parentheses while maintaining the evaluation order from the previous precedence rules. Preserving that order does not establish that it matches the programmer's intent.

The devlog illustrates the distinction with a orelse b() catch c. Previously, it grouped as (a orelse b()) catch c. Liptak suggests that a orelse (b() catch c) may make more sense, even when the result is unaffected. These are expression fragments from his migration discussion, not a standalone program or a claim that the two forms always behave differently.

Liptak recommends manual fixes as an opportunity to reconsider the intended order. If you use the formatter, review its diff for unexpected grouping. It can also add redundant parentheses that need manual cleanup.

The devlog says the --upgrade flag will be removed after one release cycle. Teams tracking master should account for that temporary migration aid when planning an upgrade.

Sources

  1. Zig devlog: Partial Operator Precedence
  2. Zig language reference: Precedence
  3. Zig issue #114: require parentheses sometimes to disambiguate confusing operator precedence