Thread by @_saagarjha

Just patched yet another project to delete a “-Werror” just so it would build on my computer and I think I’ve finally come to the conclusion that we have *really* failed at explaining why compiler warnings exist to an entire segment of programmers. We need to fix this.

The problem has gotten so bad that some of these people are *working on compilers* right now! They are literally encoding these assumptions into programming languages millions of people use. The productivity cost is real–if you use Swift or Go, you’re already living through it.

As a concept, warnings are pretty simple! They’re not that hard to understand if you approach them from the bottom up. The problems arise when you look at them in the opposite direction, without really understanding why they exist. Here, I can go through them now:

A lot of times the compiler knows what you are doing is wrong. It doesn't really know what you mean, or you’re doing something clearly invalid, so it can’t proceed. That’s when the compiler will produce an error and they’re always fatal, because there is no way forward.

Errors are all the feedback a compiler is *required* to give you. But sometimes you might write code that is valid but is not typically written: perhaps you are using an assignment for its return value, or you have written a function whose body doesn’t use all its parameters.

These are valid programs! But they might hide bugs, so the compiler can opt to provide you feedback. In most cases, you should look at what it’s saying, but the compiler can’t always get it right. Sometimes you’re going to write programs that look “fishy” but are what you wanted.

There’s a lot of reasons this can happen. The most common is that you’re in the process of iterative development, where your code is not necessarily “perfect” all the time. You’re going to be commenting things out and writing exploratory code. The compiler can’t really see this.

Development code gets deleted, though. But sometimes you really need to write programs that the compiler is going to warn about–they are legal, after all. Again, the compiler isn’t perfect, and often you have more information than it does about what you’re trying to do.

Conflating warnings and errors (as -Werror does) is wrong for both of these! For the first, you do want to see the warnings so you don’t accidentally leave ship the bad code. But while you’re developing, blocking the build until you fix evertything is a productivity drain.

For the latter, you actually do want to ship that code. What you need is a way to tell the compiler that you really *do* mean what you wrote–warning *suppression*, in other words. This lets the other warnings you actually care about not be buried in the noise.

Go does this wrong because commenting out code might mean it stops compiling, because your import is no longer used. While developing this really hurts, so much so that I know people that use a patched Go compiler locally just to get around this issue.

Swift doesn’t let you suppress warnings: what this means in practice is that people have codebases with legitimate code that has a bunch of useless warnings, or they write that code *in an entirely different language* just to escape the compiler yelling at them :/

And, as I mentioned upthread, turning on -Werror just means that your code is not going to compile on my computer when I download it, even when it is correct. The nature of warnings is that different tools can warn on different things!

The argument I get most often is “people ignore warnings if we don’t make them errors”. My response is: yes, that’s exactly what they’re for! They are informative, not prescriptive; you are meant to ignore them when they are not relevant.

The way you “ignore” them differs based on context: during development you can literally just let them be. When they appear on code you want to keep, you should suppress them so that other warnings can be more prominent.

Does this mean -Werror is useless? No, otherwise it wouldn’t exist. It’s there for contexts where you don’t actually want warnings, and the one you probably want is your main repository. It’s great for CI: you control the environment and it doesn’t affect local development.

Anyways, a TL;DR of the right way to do things:

* If you’re a language designer, allow for suppressing warnings, and don’t make things that are obviously warnings into errors
* If you maintain a project, -Werror your CI or precommit hook, not local builds