On Friday, September 28, 2018 6:50:01 AM MDT Olivier FAURE via Digitalmars-d wrote: > Warnings often catch real problems, even categories of warnings > with high amounts of false positives like unused variables. > > But yeah, I get your point. Warning lose their interest when they > start to pile up in your codebase to the point it's impossible to > notice new ones, and it's impossible to turn them into errors > because there's already too many.
> That said, that's a problem with D compilers, not with the > concept of warnings. You mention that deprecations warnings are > nice because they can be turned off; ideally, all categories of > warnings should be like that. > > What DMD and GDC lack (I think) is GCC's level of granularity, > with flags like > > -Wnonnull > -Werror=missing-attributes > -Wno-error=misleading-indentation > > But that doesn't mean the concept of compiler warnings needs to > be thrown away. Warnings are inherently are things that are not necessarily wrong and thus having them as be warned about as part of the normal part of the build is harmful, because inevitably, you either end up with them all being "fixed" even if they're not wrong, or left to pile up and become useless. That is my point. That is why they should be left up to a linter. gcc's approach really isn't an improvement. It's just changing which set of warnings you're going to have - or worse, which set of _errors_ you're going to have (i.e. -Werror). Warnings make sense when it's the programmer proactively running a tool just to look for problems and handle them individually, where it's reasonable to ignore some of them and act on others, whereas with the build step, neither of those is really true. Maybe a particularly, studious programmer could do it reasonably on a small project, but it doesn't work on anything real. Eventually, either all of the warnings get "fixed" (whether they should be or not), or you get a wall of text. Yes, some of the stuff that compilers try to warn you about can be real problems, but I think that having that be part of the normal compilation process is a huge mistake. > You mention that deprecations warnings are > nice because they can be turned off; ideally, all categories of > warnings should be like that. That wasn't my point at all, though maybe I said it badly. I actually think the fact that you can turn them off is arguably bad simply because then folks can ignore them, which causes problems in the long run, though if you somehow manage to end up with a code base that gets a ton of deprecation messages from a few deprecations, then maybe from a practical perspective, you need to be able to turn them off at least temporarily. I was trying to say that deprecations are inherently different from warnings (and the compiler treats them differently with its flags - e.g. -wi and -w have nothing do with deprecations). They're not something that the compiler thinks might be a problem but isn't smart enough to know for sure (like warnings are). They're something that _will_ be a problem but isn't a problem yet, because the deprecation period hasn't ended. They're essentially delayed errors. So, yelling at the programmer about them is okay, because it's something that they definitely need to fix and not just something that they _might_ need to fix. - Jonathan M Davis