5 comments

[ 3.2 ms ] story [ 26.8 ms ] thread
Ooh, what a nice feature! Didn't know Zig had this; thanks for the submission. Every build pipeline these days lints for it — might as well put it in the compiler.
Yeah I agree with you! Most new compilers these days are built with these kinds of diagnostics baked in from the start. Since the compiler is doing analysis anyway, it's well-positioned to expose that information to the user.

The one thing I've noticed missing from Zig's implementation is separating those diagnostics into different categories, aka errors/warnings. I can't fault them too much for the oversight since the language isn't 1.0 yet, after all. But I do look forward to them finishing this feature!

Not having warnings is intentional and seen as a feature.
It is a very unergonomic choice, though. Having warnings you can allow during development and deny in CI is the best of both worlds.

Otherwise it leads to absurd situations where some code gets commented to avoid errors caused by unused things, which defeats the point of the lint.

When coding in Rust, I extensively use warnings as a way to know what remains to be done before my code is done.

Treating all warnings as errors all the time so as to address people who would ignore warnings is overtailoring the language for beginners at the price of ergonomics for experienced programmers.

I'd agree with your last sentence if you included the inability to turn off specific warnings with source level directives. Otherwise (allowing compilation regardless of how many warnings there are) inevitably warnings do simply get ignored and just become "noise" in the compiler output.