Warn on unused imports?

[Jonathan M Davis]

On Wednesday, September 26, 2018 2:26:20 AM MDT Laurent Tréguier via 
Digitalmars-d wrote:
> On Wednesday, 26 September 2018 at 01:13:11 UTC, Jonathan M Davis
>
> wrote:
> > The way that C++ handles warnings is how I've seen most
> > languages handle warnings. 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. It's not something that should be run as part of a
> > normal build process. If it is, then inevitably what happens is
> > that either all of the warnings get "fixed" (at which point,
> > they might as well have all been errors), or they all get
> > ignored, meaning that you get a huge wall of them, and they're
> > completely useless. As such, I really have nothing good to say
> > about having any kind of warnings being built into the
> > compiler. As I understand it, on the whole, Walter agrees with
> > me and that he only added them in to dmd, because he was
> > essentially bullied into it, and I wish that he'd never given
> > in. And when you consider features like is(typeof(...)), the
> > side effects of having -w are particularly bad.
> >
> > - Jonathan M Davis
>
> I would say that at least deprecations make sense as warnings
> from the compiler. Deprecated stuff is something the user has to
> be warned about, even if they're not using a linter, since it's
> going to break at some point but should be supported for a
> minimum amount of time to ensure a smooth transition.

Errors are things that you _must_ fix, because your code is definitely
broken. Warnings are things that you _might_ need to fix or which might
actually be perfectly fine (which is why having the compiler tell you about
them as part of the normal build is such a problem). Deprecations are
basically delayed errors. They're something that you definitely need to fix,
but you don't necessarily need to fix right now. Your code isn't broken yet,
but it will be once the deprecation period ends. So, having the compiler
always tell you about the deprecation isn't a problem and in fact is
arguably desirable, since it's a constant reminder that you need to update
your code before the deprecation period ends.

IMHO, the way that dmd currently handles deprecations works quite well
overall. It simply prints a message. It's not a warning, and it's not an
error. It's just a message. You can use a compiler flag to make the message
go away or to turn it into an error (though in general, I'd advise against
it, since then your code breaks as soon as something gets deprecated), but
by default, they're just messages.

Unfortunately, if your build spits out a bunch of status stuff instead of
just printing out actual problems, deprecation messages do sometimes get
missed, which I suspect is part of why vibe.d typically does a terrible job
of getting updated when something that it uses in Phobos gets deprecated,
but there's only so much that can be done about that. Certainly, having
deprecations result in errors like they originally did with dmd makes them
untenable in general, because then simply deprecating something immediately
breaks all code that uses it, and at that point, you basically can't ever
deprecate anything.

- Jonathan M Davis