Warn on unused imports?

[Nick Sabalausky (Abscissa)]

On 10/01/2018 11:00 PM, Jonathan M Davis wrote:
> 
> The very fact that we have -w causes problems, because it forks the
> language. e.g. anyone that doesn't compile a library with -wi or -w and then
> releases it with dub can cause problems when someone else uses that project
> and then _does_ compile with -w, because suddenly, those warnings become
> errors.
> 
> And even if we only had -wi and not -w, the fact that the warnings are part
> of the compiler tends to create a culture where folks expect you to have
> them as part of your build and "fix" them all. So, while they _are_ a
> choice, IMHO, it's still a problem that they're part of the compiler, and
> IMHO, they cause more harm than good.
> 

FWIW, I'm mostly with you on "-w". I've never been a fan of it and see 
very little point to it (like you said, it just turns them into optional 
errors). On the -wi, well, we disagree.

> I don't want the compiler to ever be telling me something that isn't
> guaranteed to be a problem. Period. I am sick and tired of compilers
> spitting out junk that's wrong that has to be "fixed" to shut it up.

C++ seems to have really given you the wrong idea about warnings. The 
way it SHOULD work (and typically does in D) is that most warnings are 
things that YES, most likely SHOULD be fixed, but aren't worth 
*immediately* blocking the developer from whatever they're currently in 
the middle of.

Additional, more pedantic lint-y warnings can be added under separate 
cmdline flags. And if some shitty dev team tries to treat THOSE ones as 
errors, then that's on them, it's not as if taking that one thing away 
is going to magically turn them competent.

> 
> Deprecations are an entirely different beast, because they're telling you

Honestly, what I'm really hearing here is that deprecations are 
different because they're the one warning you personally aren't annoyed 
by...

> about something that you definitely must fix, but they're not errors,
> because if they were, then deprecating anything would break code
> immediately, which would mean that we could never deprecate anything,
> because it would break code, and people would scream. By having it just
> print a message and allowing folks to either fix their code immediately or
> put it off, we avoid that immediate breakage. But eventually, they're going
> to have to fix their code or incur the breakage, which is in stark contrast
> to warnings, which could be useful information, or they could be utterly and
> completely wrong - but either way, because they get spit out as part of the
> build, you're forced to "fix" them.

You're mostly right about deprecations here, but largely off-the-mark on 
the other warnings. Again, from what you're saying here, I'm still 
getting the impression that you're subconsciously equating "warnings" 
with "C++ -Wall".

> Anyway, as I said before, we're clearly not going to agree here. And we seem
> to just be getting less civil about the whole thing. I absolutely detest
> warnings, think that they have no business in compilers, and want them in a
> separate tool designed to help the programmer find bugs in their program and
> not be anywhere near the build process, whereas you like warnings, think
> that they're helpful more often than not, and want them to be part of the
> compiler.

Well, granted, that's what we seem to have gotten off-track to. But 
really, my main original point is not "warnings good". It's just this:

"$ toolA --do-xyz" == "$ tool-xyz"

Side A: We call "warnings"
Side B: We call "lint"

Aside from that, there's no fundamental difference.