Warn on unused imports?

[FeepingCreature]

On Wednesday, 26 September 2018 at 16:29:24 UTC, Neia Neutuladh 
wrote:
> * If you encounter a mixin in the module you're analyzing, give 
> up.

Unfortunately, our code uses mixins heavily, so I don't think 
this would be useful for us.

In any case, I fundamentally don't consider the approach of "well 
if you want *this* side of D, you can't use *that* side of D" an 
acceptable way to find solutions.

To weigh in on the warnings debate, while I generally think that 
warnings being fine-grained toggleable makes sense, I also think 
it's correct for this specific feature to be a warning, because 
it's only useful if you're using D in a certain mode (one-shot 
recursive compilation of a closed set of source files into a 
binary), which just happens to also be the mode that most of our 
code uses.

In any case, the linter/compiler separation simply does not make 
sense for D, simply because the language is under heavy 
development and having the linter depend on the same frontend as 
the compiler means you're perennially forced to develop to the 
intersection subset of compiler-supported features and 
linter-supported features. Even with a pure-syntax linter like 
D-Scanner, we've ran into this issue quite recently with the in() 
contract syntax change causing breakage all over Github. The only 
sane way to write a semantic linter in D is to ship the DMDFE as 
a global library with a stable interface that linters can link 
against, so you can upgrade DMD and get a linter frontend upgrade 
"for free", or else as a tool shipped with the compiler distro so 
that it's again linked against the same code. In any case, this 
approach is still inherently inefficient because you're 
essentially compiling the *exact same* code twice in a row, since 
in modern D at least 50% of the time is spent in the frontend. It 
makes more sense, in my opinion, both from a design and 
performance perspective to process the information in the natural 
place it is produced in the first place - the frontend. Making 
DMD available as a library with a stable API is a good second 
place. Hell, even allowing DMD plugins to load from the 
commandline (with a semistable API) would work. Making DMD 
available as a non version tagged separate package so that you 
have to rebuild all your tools during a compiler upgrade, 
manually checkout a specific revision of the DMD repo, hodge 
together a manual build process because dub, D's native package 
system can't be used due to some weird insistence on keeping 
strict semver on the dub side and arbitrarily violating semver on 
the DMD side, so that you then have to manually run the D compile 
workflow in order to finally dump some information that you 
immediately read back in and output as warnings - I cannot see 
this as a sane approach.