Werror means as soon as someone uses a new compiler with a new warning your code stops building. Even if it's something about misleading parenthesis or brace position. It's not a good thing to have on by default in build script.
But that is still a problem specific to C, not warnings in general.
First of all, languages with less legacy constraints can have the line between warnings and errors in the right place, so users don't have the need to turn all warnings into errors. Werror can be reduced from being the best practice to just overly cautious pedantism.
Then, even Werror can be made more robust. Rust solves this in a few ways:
• cap-lints: it suppresses its Werror equivalent when building someone else's code (dependencies), so the code you can't fix yourself won't break on you due to just a lint.
• editions: Bigger language changes that could render old code incompatible are gated behind the edition setting, which is an opt-in to new stuff, including some new warnings.
• `allow(warning_id)`: you can put it on any code block or even the whole project. So even if you get a new warning that is a false positive or just don't have time to deal with it, you can reliably and precisely turn it off in the source code (as opposed to compiler-specific flags, #pragmas, or reshuffling the code until the warning goes away).
• clippy: all the weaker, experimental, and more opinionated warnings are in a separate tool. The compiler proper adopts clippy's warnings only if they prove to be useful. The type of people who use Werror use clippy, so they'll likely have their codebase clean of these warnings before they make it to the compiler.
You should have it on for CI and for first party developers by default, but have it off if you distribute your source to third parties for the reason you stated.
That's kind of my point. C/C++ have a really bad implementation of warnings, which leads people to think that warnings are fundamentally a bad idea, which is not something I am convinced by.
I think people should look at the output of their compiler and fix warnings before checking in code.
And frankly I'd rather the build not stop on the first error. In fact it would be best if the build system tried to link even if there are errors. Might work.
> I think people should look at the output of their compiler and fix warnings before checking in code.
I agree, but I don't think they should be required to fix all warnings before checking in code, which is what no-warnings languages like Go require.
> And frankly I'd rather the build not stop on the first error. In fact it would be best if the build system tried to link even if there are errors. Might work.
Not sure what your point is here. Most compilers don't stop on the first error.
