Warn on unused imports?

[Jonathan M Davis]

On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 09/25/2018 09:13 PM, Jonathan M Davis wrote:
> > IMHO, the only time that anything along the lines of a warning
> > makes sense is when the programmer is proactively running a tool to
> > specifically ask to be informed of a potential type of problem where
> > they
> > will then go look at each of them individually and decide whether what
> > the tool is telling them is valid or not - at which point, some of what
> > the tool says will be followed, and some if it will be ignored.
>
> Yes, that's exactly what warnings are for. If people need to treat them
> differently than that (ex: C++), that's a failing of the language.

As soon as warnings are part of the build process, that's not how they're
treated. I have _never_ seen them treated that way. That's not to say that
no one ever has done it, but I have consistently seen that what happens is
that either they're either all "fixed," or they're left on, generating a
wall of text. And I've seen it with more than just C++ or D (though in D, we
have very few warnings, and the typical approach is to either not turn them
on or to use -w, which means that you can get different semantics depending
on how the code was compiled, so we end up with a different set of
problems).

But I honestly don't see how you can expect any project to _not_ end up with
most warnings either being "fixed" or ignored when the compiler throws a
whole wall of text at you about what _might_ be wrong with your program
during the normal build process. If you don't "fix" them all, then you
always have a wall of text, and it makes it very difficult to find the ones
that matter. And if you do "fix" them, then you're making all kinds of
unnecessary (and potentially wrong) changes to your code just to shut the
compiler up. Sure, when a project first starts, there may not be very many
warnings, but they're quickly going to spiral out of control as it increases
in size unless you "fix" them all as you go along or the compiler is
actually smart enough to only tell you when your code is actually wrong. And
if the compiler is guaranteed to be right about it, then it should be an
error, not a warning.

IMHO, if warnings are part of the normal build process, then there's a
serious problem with them.

> Plus, other warnings (like deprecations, for example) which have proven
> extremely helpful would have been a major problem had they been outright
> errors.

Technically, deprecations aren't warnings, and dmd treats them quite
differently. They aren't affected by either -wi or -w, and from a semantic
perspective, they're completely different. Warnings are something where the
compiler is telling you about something that _might_ be wrong with your
code. Deprecations are telling you something that _will_ be wrong with your
code (but isn't yet), so you're going to have to fix it before the
deprecation period expires, but you don't have to immediately. So, while the
the help output from the compiler does unfortunately call deprecation
messages "deprecation warnings" instead of deprecation messages,
"deprecation warnings" and regular "warnings" are actually completely
different, both in principle and in terms of how the compiler treats them.
They're very much their own thing, and they don't have the same problems
that regular warnings do.

> And realistically, I, and likely most of us, frequently wouldn't have
> bothered if they had been in a separate a tool, certainly not before
> every commit. (Right, as if most C programmers actually *use* lint
> regularly?) It's the same "built-in unittests and docs" effect.

That's a valid point. A separate tool is less likely to be used, but
honestly, from everything I've seen of warnings and how they've been used, I
think that they do far more harm than good in general if they're just a
compiler flag. And since I really think that the correct way to handle them
is for a responsible programmer to proactively run a tool to figure out what
problems might exist in his code anyway (just like he might choose to run a
fuzzer on it to find problems), I don't think that it's ultimately a
problem. Though I think that it's pretty clear that we're going to have to
agree to disagree on that.

- Jonathan M Davis