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

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.