The Zig compiler is now lazier about analyzing the fields of types: if the type is never initialized, then there’s no need for Zig to care what that type “looks like”. This is important when you have a type which doubles as a namespace, a common pattern in modern Zig. [...example...] Previously, this code emitted a compile error. Now, it compiles just fine, because Zig never actually looks at the @compileError call.
This is done for the best of reasons, in a clear and consistent way, but it still feels incredibly spooky. Zig is already incredibly lazy about what it compiles compared to just about every other language I know. I want programs that work or don't work, not ones that work situationally based off of arbitrary factors that may occur far away from the error. It seems like the ultimate Works On My Machine enabler. It's basically C #ifdef directives raised to the next level, and I have to wonder how many people have run into programs where the not-taken path in an #ifdef has been broken for ages just because nobody used it... up until one day they needed to.
But I don't have much experience with Zig in practice, so maybe I'm just paranoid.
As a maintainer of a relatively larger Zig project over many years (Ghostty), I can say that yes, this absolutely happens. The most spooky part isn't really the runtime paths, but the test time paths. Since tests are also only run if their container is referenced, I've had scenarios where we've had broken edge case functionality for an unknown but long time because the test wasn't actually running (aghhhhh).
In general, the lazy analysis of Zig is a godsend and I wouldn't trade it out. It enables really elegant cross-platform/cross-config code all within the same file/functions/expressions because non-referenced paths don't get analyzed so you can just for example call Windows APIs wherever and gate it on a comptime condition (target is windows) and it'll just build perfectly everywhere else. This is critical and we use it constantly and everywhere in Ghostty.
I don't know what the right solution is but I feel like I basically want to create a human/machine readable manifest of what tests ran (or maybe even more generally what codepaths) and be able to commit that alongside my code so that future test runs in CI can fail if that path changes unexpectedly. I don't know!
This is exactly my experience as well. It’s also anxiety inducing when you’re working on a smaller project where zig build test --watch is so fast that you can’t tell if it actually did anything lol
icefox | 3 hours ago
This is done for the best of reasons, in a clear and consistent way, but it still feels incredibly spooky. Zig is already incredibly lazy about what it compiles compared to just about every other language I know. I want programs that work or don't work, not ones that work situationally based off of arbitrary factors that may occur far away from the error. It seems like the ultimate Works On My Machine enabler. It's basically C
#ifdefdirectives raised to the next level, and I have to wonder how many people have run into programs where the not-taken path in an#ifdefhas been broken for ages just because nobody used it... up until one day they needed to.But I don't have much experience with Zig in practice, so maybe I'm just paranoid.
mitchellh | an hour ago
As a maintainer of a relatively larger Zig project over many years (Ghostty), I can say that yes, this absolutely happens. The most spooky part isn't really the runtime paths, but the test time paths. Since tests are also only run if their container is referenced, I've had scenarios where we've had broken edge case functionality for an unknown but long time because the test wasn't actually running (aghhhhh).
In general, the lazy analysis of Zig is a godsend and I wouldn't trade it out. It enables really elegant cross-platform/cross-config code all within the same file/functions/expressions because non-referenced paths don't get analyzed so you can just for example call Windows APIs wherever and gate it on a comptime condition (target is windows) and it'll just build perfectly everywhere else. This is critical and we use it constantly and everywhere in Ghostty.
I don't know what the right solution is but I feel like I basically want to create a human/machine readable manifest of what tests ran (or maybe even more generally what codepaths) and be able to commit that alongside my code so that future test runs in CI can fail if that path changes unexpectedly. I don't know!
zmitchell | 42 minutes ago
This is exactly my experience as well. It’s also anxiety inducing when you’re working on a smaller project where
zig build test --watchis so fast that you can’t tell if it actually did anything lol[OP] rcalixte | 17 hours ago
New devlog entry from March 10, 2026 about the type resolution pull request that was recently merged.