Warn on unused imports?

[Jonathan M Davis]

On Monday, October 1, 2018 8:03:39 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 10/01/2018 04:58 PM, Jonathan M Davis wrote:
> > On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via
> >
> > Digitalmars-d wrote:
> >> Nobody said anything about making them part of the build process. We're
> >> talking about them being included in the compiler, not about them being
> >> in the build process. Please don't move the goalposts.
> >
> > dmd -w
> >
> > and
> >
> > dmd -wi
> >
> > build your program. Printing warnings is part of the build process.
>
> dmd
>
> or
>
> dmd -w -o-
>
> Just like external tools, they're NOT part of the build process unless
> you CHOOSE to make them part of your build process. (Though, with
> external tools, there's an unavoidable added performance penalty. But if
> you don't want them part of the build then I guess that penalty becomes
> moot.)

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.

> >> That is purely playing around with word semantics. Deprecations in DMD
> >> are a non-fatal message about something that might need fixed sooner or
> >> later. That is what a warning is. Implementation details do nothing to
> >> change that.
> >
> > Deprecations are fundamentally different from compiler warnings. In the
> > case of a deprecation, your code _will_ break if you don't change it
> > once the deprecation period ends, whereas a compiler warning is just
> > telling you about something that the compiler thinks might be wrong
> > wiith your code.
> If not fixing it *will* cause breakage then, by your stance, shouldn't
> it be an error (or silence)? I thought you were against the build
> process pointing out issues with your code without making them outright
> errors?
>
> If you're opposed to a warnings' non-error status because the warning
> *might* indicate a problem, then *certainly* you'd also be opposed to
> non-error status for something that *will* be a problem, right? Do you
> *really* consider "maybe a problem" more serious than "definitely a
> problem"?
>
> But you're splitting hairs anyway. Either way, you have things that
> likely[1] should be improved (or at least looked into), but don't
> immediately require action. Fundamentally, same effing thing.
>
> [1] Yes, the strength of this "likely" varies from warning to warning.
> But it does so even aside from deprecations.

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.

Deprecations are an entirely different beast, because they're telling you
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.

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. We have pretty much opposite positions on the matter and at best
are going to agree to disagree. I don't think that discussing it further is
really going to help anyone.

- Jonathan M Davis