Warn on unused imports?

[Jonathan M Davis]

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