There are two times when a compiler is being used, the first is when the developer is writing the code, the second is when an end user or packager is building the package from source. The second use case is actually done far more often for popular software, but is seriously under served by compiler writers. For packagers, compiler warnings do a few things:
- Break the build when -Werror is enabled and different compilers add new diagnostics.
- Train people to ignore messages from the compilers.
- Waste CPU time by checking things the person has no ability to fix anyway.
- Look ugly.
My proposal is simple. Shift all warnings from compilers and into code analysis tools that are as easy to run as the compiler itself. That way programmers get good warnings and our compilers can be faster and less annoying for everyone else. The Go programming language designers already realized this, with a compiler that emits no warnings, and excellent tools for catching bugs (https://golang.org/cmd/vet/, https://github.com/golang/lint).
Whatever happened to do one thing, and one thing well. Compiler warnings are bad design.