Re: Warn on unused imports?

[JN via Digitalmars-d]

On Wednesday, 3 October 2018 at 17:33:43 UTC, Dennis wrote:
Sure, the Unix way is a nice philosophy, but let's face the 
facts:
- Because of (amongst others) CTFE and mixin, D is an 
incredibly complicated language to reason about (unlike Java or 
C#)
- There is only one D front-end, and it will likely stay that 
way for a while
- Any static analysis tool that doesn't only work with a subset 
of the language must basically re-implement a complete compiler 
front-end or leverage dmd


This is a big point actually. There are several design choices in 
D that were made for the ease of parsability of the code, for 
example using !() instead of <> (personally I think <> look much 
cleaner, but I understand how it's harder to parse).



As for the thread. I think this could work either as a warning or 
in the compiler. The problem with making it a warning is that 
people might want to disable the feature once it breaks the 
build. It's a big pain in Go. Imagine importing a logger, and 
then putting some log methods int he code. Everything is fine. 
Then you comment out the log lines just for a moment, and bam, 
import logger is unnecessary and your build breaks.

Re: Warn on unused imports?

[Patrick Schluter via Digitalmars-d]

On Thursday, 4 October 2018 at 18:55:01 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 09/26/2018 06:00 AM, Anonymouse wrote:
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


Would just like to say that I love the idea and would use it 
immediately.


Same here. Periodically, my import lists tend to turn into 
giant outdated blobs of everything ever used by my project. But 
pruning them is a major involvement involving many, many cycles 
of pure trial-and-error. I've often wanted a way to say "Hey, 
just TELL me which imports are unused, so I don't have to spend 
half the afternoon manually testing them all!"


Exactly. Even me with my very low usage of D have already been 
confronted with that. A wall of outdated imports which requires 
real involvement to clean up.
An optional warning to tell which are not used would be already a 
good step.

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 09/26/2018 06:00 AM, Anonymouse wrote:

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:

I'm playing with a branch of DMD that would warn on unused imports:


Would just like to say that I love the idea and would use it 
immediately.


Same here. Periodically, my import lists tend to turn into giant 
outdated blobs of everything ever used by my project. But pruning them 
is a major involvement involving many, many cycles of pure 
trial-and-error. I've often wanted a way to say "Hey, just TELL me which 
imports are unused, so I don't have to spend half the afternoon manually 
testing them all!"

Re: Warn on unused imports?

[Dennis via Digitalmars-d]

On Wednesday, 3 October 2018 at 14:27:42 UTC, Dejan Lekic wrote:
IDK, I prefer things done in the UNIX way - do one thing and do 
it right. Compiler should do what its name says - COMPILE, 
while some other tool should be made for these kind of code 
checks. The code will compile no matter whether there are some 
unused imports or not, right?


Sure, the Unix way is a nice philosophy, but let's face the facts:
- Because of (amongst others) CTFE and mixin, D is an incredibly 
complicated language to reason about (unlike Java or C#)
- There is only one D front-end, and it will likely stay that way 
for a while
- Any static analysis tool that doesn't only work with a subset 
of the language must basically re-implement a complete compiler 
front-end or leverage dmd


Also dmd is currently not following the Unix way by a long shot. 
You could have separate programs for the optimizer and assembler, 
like some compilers have. Every stage of compilation could be a 
separate program, and that would even be beneficial to static 
analysis tools, but that has other problems too (like changes in 
the API, worse performance because of text input and output).


Currently we have a package that does everything that requires 
intricate knowledge of the D language: compiling, documentation 
generation, profiling, and warning about things like dead code. 
Also unit-testing is part of the language and the standard 
library is huge. Warning about unused imports seems like a useful 
addition to me.

Re: Warn on unused imports?

[Dejan Lekic via Digitalmars-d]

On Thursday, 27 September 2018 at 18:35:58 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 09/26/2018 04:37 AM, Dejan Lekic wrote:
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


I humbly believe this does not belong to the compiler. These 
sort of things belong to a static code analyser TOOL. Think of 
checkstyle/findbugs in Java, or flake8/pep8 in Python world.


It amounts to the same thing. What you're talking about 
ultimately boils down to nothing more than the trivial 
distinction between:


toolx ...
toola --do-x ...

And if you still prefer the former, that can be trivially 
created via shell alias or a one-liner script.


OTOH, If you're talking about whether action X should be taken 
by default, than that's an entirely orthogonal matter to 
whether or not it can be included in the compiler.


IDK, I prefer things done in the UNIX way - do one thing and do 
it right. Compiler should do what its name says - COMPILE, while 
some other tool should be made for these kind of code checks. The 
code will compile no matter whether there are some unused imports 
or not, right?

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

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

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.)



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.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 10/01/2018 03:32 PM, Jonathan M Davis wrote:
> > On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa)
> > via
> >
> > Digitalmars-d wrote:
> >> 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,
>
> 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.

> >> 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.
>
> 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. In
some cases, it's right; in some cases, it's wrong. In the case of
deprecations, it's always right, and you always have to change your code.
You just don't have to change it immediately.

- Jonathan M Davis

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 10/01/2018 03:32 PM, Jonathan M Davis wrote:

On Monday, October 1, 2018 12:36:49 PM MDT Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:


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,


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.




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.


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.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

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

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.


> 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),

They only "might as well have all been errors" if the programmer always 
fixes them all before running any of his intermediary builds. It's one 
matter if it's right before a release or often a VCS commit, but plenty 
of very helpful messages can become a major pain while *developing* an 
individual commit.


> or they all get
> ignored, meaning that you get a huge wall of them, and
> they're completely useless.

I'd probably have a tendency to fall into one of those two traps too if 
I were using C++. Outside of C++, I'm not in either of those categories. 
So, so much for that false dichotomy being "inevitable".



As such, I really have nothing good to say about having any kind of
warnings being built into the compiler.


Whether or not they're built into the compiler is completely orthogonal 
to the acceptable use-case you described above.



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'm very glad he was, because many of those warnings have saved my 
ass on more than one occasion, but would've been completely non-existent 
it if were completely up to Walter.


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


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.

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

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.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

On Friday, September 28, 2018 6:50:01 AM MDT Olivier FAURE via Digitalmars-d 
wrote:
> Warnings often catch real problems, even categories of warnings
> with high amounts of false positives like unused variables.
>
> But yeah, I get your point. Warning lose their interest when they
> start to pile up in your codebase to the point it's impossible to
> notice new ones, and it's impossible to turn them into errors
> because there's already too many.

> That said, that's a problem with D compilers, not with the
> concept of warnings. You mention that deprecations warnings are
> nice because they can be turned off; ideally, all categories of
> warnings should be like that.
>
> What DMD and GDC lack (I think) is GCC's level of granularity,
> with flags like
>
>  -Wnonnull
>  -Werror=missing-attributes
>  -Wno-error=misleading-indentation
>
> But that doesn't mean the concept of compiler warnings needs to
> be thrown away.

Warnings are inherently are things that are not necessarily wrong and thus
having them as be warned about as part of the normal part of the build is
harmful, because inevitably, you either end up with them all being "fixed"
even if they're not wrong, or left to pile up and become useless. That is my
point. That is why they should be left up to a linter.

gcc's approach really isn't an improvement. It's just changing which set of
warnings you're going to have - or worse, which set of _errors_ you're going
to have (i.e. -Werror). Warnings make sense when it's the programmer
proactively running a tool just to look for problems and handle them
individually, where it's reasonable to ignore some of them and act on
others, whereas with the build step, neither of those is really true. Maybe
a particularly, studious programmer could do it reasonably on a small
project, but it doesn't work on anything real. Eventually, either all of the
warnings get "fixed" (whether they should be or not), or you get a wall of
text.

Yes, some of the stuff that compilers try to warn you about can be real
problems, but I think that having that be part of the normal compilation
process is a huge mistake.

> You mention that deprecations warnings are
> nice because they can be turned off; ideally, all categories of
> warnings should be like that.

That wasn't my point at all, though maybe I said it badly. I actually think
the fact that you can turn them off is arguably bad simply because then
folks can ignore them, which causes problems in the long run, though if you
somehow manage to end up with a code base that gets a ton of deprecation
messages from a few deprecations, then maybe from a practical perspective,
you need to be able to turn them off at least temporarily. I was trying to
say that deprecations are inherently different from warnings (and the
compiler treats them differently with its flags - e.g. -wi and -w have
nothing do with deprecations). They're not something that the compiler
thinks might be a problem but isn't smart enough to know for sure (like
warnings are). They're something that _will_ be a problem but isn't a
problem yet, because the deprecation period hasn't ended. They're
essentially delayed errors. So, yelling at the programmer about them is
okay, because it's something that they definitely need to fix and not just
something that they _might_ need to fix.

- Jonathan M Davis

Re: Warn on unused imports?

[Olivier FAURE via Digitalmars-d]

On Wednesday, 26 September 2018 at 09:25:11 UTC, Jonathan M Davis 
wrote:
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.


That's precisely what warnings are: messages that can be silenced 
or turned into errors. When people talk about warnings, that's 
usually what they mean.


Personally speaking, I like to treat warnings as problems that 
don't stop your code from compiling during development (eg I 
don't want to worry about my extranous return statements when I'm 
doing quick experiments), but can't be accepted upstream, and 
have to trigger errors in CI.


But with a robust warning system, other approaches are possible.

Unfortunately, if your build spits out a bunch of status stuff 
instead of just printing out actual problems, deprecation 
messages do sometimes get missed


Warnings often catch real problems, even categories of warnings 
with high amounts of false positives like unused variables.


But yeah, I get your point. Warning lose their interest when they 
start to pile up in your codebase to the point it's impossible to 
notice new ones, and it's impossible to turn them into errors 
because there's already too many.


That said, that's a problem with D compilers, not with the 
concept of warnings. You mention that deprecations warnings are 
nice because they can be turned off; ideally, all categories of 
warnings should be like that.


What DMD and GDC lack (I think) is GCC's level of granularity, 
with flags like


-Wnonnull
-Werror=missing-attributes
-Wno-error=misleading-indentation

But that doesn't mean the concept of compiler warnings needs to 
be thrown away.

Re: Warn on unused imports?

[Jacob Carlborg via Digitalmars-d]

On Wednesday, 26 September 2018 at 15:57:57 UTC, rikki cattermole 
wrote:


For those who are unaware, dmd-fe for usage as a library is 
completely worthless currently. So not having the tags is 
probably a good thing.


For those who are unaware I'm using it in one of my projects [1] 
and so far everything is working as expected ;). So no, it's not 
completely worthless.


[1] http://github.com/jacob-carlborg/dlp

--
/Jacob Carlborg

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 09/26/2018 04:37 AM, Dejan Lekic wrote:

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:

I'm playing with a branch of DMD that would warn on unused imports:


I humbly believe this does not belong to the compiler. These sort of 
things belong to a static code analyser TOOL. Think of 
checkstyle/findbugs in Java, or flake8/pep8 in Python world.


It amounts to the same thing. What you're talking about ultimately boils 
down to nothing more than the trivial distinction between:


toolx ...
toola --do-x ...

And if you still prefer the former, that can be trivially created via 
shell alias or a one-liner script.


OTOH, If you're talking about whether action X should be taken by 
default, than that's an entirely orthogonal matter to whether or not it 
can be included in the compiler.

Re: Warn on unused imports?

[Neia Neutuladh via Digitalmars-d]

On 09/26/2018 02:51 AM, FeepingCreature wrote:

On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic wrote:
I humbly believe this does not belong to the compiler. These sort of 
things belong to a static code analyser TOOL. Think of 
checkstyle/findbugs in Java, or flake8/pep8 in Python world.


I can't put it differently than this: you're simply wrong, in my 
opinion. It's *provably impossible* do do this statically.


I think you can do some amount of it statically:

* List out the symbols each module exports.
* List out the symbols that appear in source code.
* If you find that a module doesn't export a symbol that this code uses, 
recommend its deletion.
* If you encounter a mixin in a module that's visible to it, assume that 
module is required. (Optional: require that mixin to be at module scope.)

* If you encounter a mixin in the module you're analyzing, give up.

So that's at least 80 modules in Phobos that you might be able to 
suggest not importing.

Re: Warn on unused imports?

[rikki cattermole via Digitalmars-d]

On 27/09/2018 3:53 AM, Neia Neutuladh wrote:

On 09/26/2018 12:39 AM, FeepingCreature wrote:

On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote:
The DMD compiler is available as a library. A linter tool can be 
based on that.


Repeating it here: the library does not have version-tagged releases. 
For a build system based around reproducible builds, this makes it 
completely unusable.


It means you need to use git submodules and depend on a specific version 
that way. And that means you can't tell why you chose a particular 
revision.


For those who are unaware, dmd-fe for usage as a library is completely 
worthless currently. So not having the tags is probably a good thing.

Re: Warn on unused imports?

[Neia Neutuladh via Digitalmars-d]

On 09/26/2018 12:39 AM, FeepingCreature wrote:

On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg wrote:
The DMD compiler is available as a library. A linter tool can be based 
on that.


Repeating it here: the library does not have version-tagged releases. 
For a build system based around reproducible builds, this makes it 
completely unusable.


It means you need to use git submodules and depend on a specific version 
that way. And that means you can't tell why you chose a particular revision.

Re: Warn on unused imports?

[drug via Digitalmars-d]

26.09.2018 13:00, Anonymouse пишет:

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote:

I'm playing with a branch of DMD that would warn on unused imports:


Would just like to say that I love the idea and would use it 
immediately. Currently going through old code that evolved too 
organically, with imports too far away from where they were originally 
(but no longer) used.
more over during refactoring it can results in recursive template 
instantiating. And compiler isn't helpful in resolving it.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 26, 2018 4:46:23 AM MDT Laurent Tréguier via 
Digitalmars-d wrote:
>  From dmd's help:
> ```
>-dsilently allow deprecated features
>-dw   show use of deprecated features as warnings
> (default)
>-de   show use of deprecated features as errors
> (halt compilation)
> ```
> Deprecations are shown as warnings and not simple messages it
> seems. But this is probably just a matter of wording here, so not
> really relevant I think.

It's definitely a matter of wording and thus arguably should be changed. For
instance, if they were actually warnings, -w would turn a deprecation
message into an error like -de does, and it doesn't. They're frequently
called deprecation warnings, so it's no surprise that the flag would be -dw
or that the help information would say that, but from the stand point of
what flags like -w consider to be warnings, they're not warnings.

- Jonathan M Davis

Re: Warn on unused imports?

[Laurent Tréguier via Digitalmars-d]

On Wednesday, 26 September 2018 at 09:25:11 UTC, Jonathan M Davis 
wrote:
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.


From dmd's help:
```
  -dsilently allow deprecated features
  -dw   show use of deprecated features as warnings 
(default)
  -de   show use of deprecated features as errors 
(halt compilation)

```
Deprecations are shown as warnings and not simple messages it 
seems. But this is probably just a matter of wording here, so not 
really relevant I think.


Beyond that I agree with the idea of letting linters and the like 
point out bad practices or suspicious things such as unused 
imports; as a compiler's role is to compile, while a linter's 
role is to lint.

Re: Warn on unused imports?

[Dennis via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


Cool that you're working on this!

Re: Warn on unused imports?

[Anonymouse via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


Would just like to say that I love the idea and would use it 
immediately. Currently going through old code that evolved too 
organically, with imports too far away from where they were 
originally (but no longer) used.

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Wednesday, 26 September 2018 at 08:37:12 UTC, Dejan Lekic 
wrote:
I humbly believe this does not belong to the compiler. These 
sort of things belong to a static code analyser TOOL. Think of 
checkstyle/findbugs in Java, or flake8/pep8 in Python world.


I can't put it differently than this: you're simply wrong, in my 
opinion. It's *provably impossible* do do this statically.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

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

Re: Warn on unused imports?

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature 
wrote:
On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes 
Scherkl wrote:

template from(string moduleName)
{
  mixin("import from = " ~ moduleName ~ ";");
}


class TestException(T) : from!"std.format".FormatException?

That should work, but it's kind of a big step. In any case, 
I'll never get a weird hacky template like that through code 
review :)

That "weird" template is about to be added to phobos.
Since its invention one and a half year ago I use it pretty much 
everywhere in my code for parameters that otherwise would require 
a global import. I just wasn't sure if it would work in this 
place too (that usecase never arose to me).
I don't understand, why a standard template wouldn't pass a 
review.

Re: Warn on unused imports?

[Dejan Lekic via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


I humbly believe this does not belong to the compiler. These sort 
of things belong to a static code analyser TOOL. Think of 
checkstyle/findbugs in Java, or flake8/pep8 in Python world.


I think developing such tool as part of the D Language team group 
(GitHub) makes more sense than anything else...

Re: Warn on unused imports?

[Laurent Tréguier via Digitalmars-d]

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.

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Wednesday, 26 September 2018 at 01:13:11 UTC, 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.



- Jonathan M Davis


Yeah, that's exactly how I ended up doing it, as an additional 
part of the -deps info. See 
https://github.com/dlang/dmd/pull/8740 .

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Tuesday, 25 September 2018 at 19:28:47 UTC, Jacob Carlborg 
wrote:
The DMD compiler is available as a library. A linter tool can 
be based on that.


Repeating it here: the library does not have version-tagged 
releases. For a build system based around reproducible builds, 
this makes it completely unusable.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 25, 2018 1:21:50 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 09/25/2018 09:14 AM, Jonathan M Davis wrote:
> > On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via
> >
> > Digitalmars-d wrote:
> >> I'm playing with a branch of DMD that would warn on unused
> >> imports:
> >>
> >> https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-> 
> >> >> unu sed-imports
> >>
> >> Two problems have arisen.
> >>
> >> First:
> >>
> >> import std.stdio;
> >>
> >> void foo(T)() { writeln("Hello World"); }
> >>
> >> foo.d: Warning: unused import
> >>
> >> To be fair, it's not *wrong*: if you remove the import, the
> >> module itself compiles just fine. In any case, it's trivial to
> >> instead move the import into the template.
> >>
> >> The real problem is this:
> >>
> >> import std.format;
> >>
> >> class TestException(T) : FormatException { }
> >>
> >> Now I can't move the import inside the template, because it's
> >> needed at the point of instantiation, but not inside the template
> >> scope *per se*.
> >>
> >> I could require the class to be written as
> >>
> >> template TestException(T) {
> >>
> >> import std.format;
> >> class TestException : FormatException { }
> >>
> >> }
> >>
> >> but that's kind of terrible.
> >>
> >> I've been working around this for now, with import std.format :
> >> FormatException, but I'm not really happy with it.
> >>
> >> Any ideas?
> >
> > Honestly, in general, warnings are a terrible idea. Anything that's a
> > warning in your code has to be fixed, because it's bad practice to leave
> > warnings in your code, meaning that ultimately, there's not much
> > difference between a warning and an error. To make matters worse,
> > there's a compiler flag that turns warnings into errors. And when you
> > combine that with stuff like is(typeof(...)) and template constraints,
> > whether you use that compiler flag or not could actually change the
> > resulting program. So, as it stands, warnings are an even worse idea in
> > D than they are in other languages. Walter likes to talk about how
> > warnings in C/C++ are there simply because folks couldn't agree on what
> > should or shouldn't be an error in the language.
> >
> > If something is definitively wrong, then it should be an error. If it's
> > not definitively wrong, then the compiler shouldn't say anything about
> > it, and it should be left up to a linter tool of some kind like dcd.
>
> Warnings ARE a lint tool. The only reason people have gotten the idea
> they're basically toggleable errors is because of the horrid mess that
> is C/C++, where it's common practice to permit things that no sane
> language would ever even CONSIDER not making a big, giant flashing
> sirens-blazing error (thus necessitating, at very least, a warning).
> Hell, even the actual lint tools in C/C++ land spit out tons of stuff
> that should be errors.
>
> Summary: Warning are not bad. The C/C++ approach to warnings is bad, and
> had corrupted millions of programmer's minds.

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

Re: Warn on unused imports?

[Jacob Carlborg via Digitalmars-d]

On 2018-09-25 16:20, FeepingCreature wrote:

If that's the way D wanted to go, it shouldn't have turned itself into a 
metaprogramming monster that's completely unevaluable by Linter tools, 
*or* it should offer some way to dump a fixed-format lowered 
representation with line number information that tools can analyze. As 
it stands, it is literally impossible to evaluate whether an import is 
unused without evaluating the entire compile-time subset of D.


The DMD compiler is available as a library. A linter tool can be based 
on that.


--
/Jacob Carlborg

Re: Warn on unused imports?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 09/25/2018 09:14 AM, Jonathan M Davis wrote:

On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via
Digitalmars-d wrote:

I'm playing with a branch of DMD that would warn on unused
imports:

https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unu
sed-imports

Two problems have arisen.

First:

import std.stdio;

void foo(T)() { writeln("Hello World"); }

foo.d: Warning: unused import

To be fair, it's not *wrong*: if you remove the import, the
module itself compiles just fine. In any case, it's trivial to
instead move the import into the template.

The real problem is this:

import std.format;

class TestException(T) : FormatException { }

Now I can't move the import inside the template, because it's
needed at the point of instantiation, but not inside the template
scope *per se*.

I could require the class to be written as

template TestException(T) {
import std.format;
class TestException : FormatException { }
}

but that's kind of terrible.

I've been working around this for now, with import std.format :
FormatException, but I'm not really happy with it.

Any ideas?


Honestly, in general, warnings are a terrible idea. Anything that's a
warning in your code has to be fixed, because it's bad practice to leave
warnings in your code, meaning that ultimately, there's not much difference
between a warning and an error. To make matters worse, there's a compiler
flag that turns warnings into errors. And when you combine that with stuff
like is(typeof(...)) and template constraints, whether you use that compiler
flag or not could actually change the resulting program. So, as it stands,
warnings are an even worse idea in D than they are in other languages.
Walter likes to talk about how warnings in C/C++ are there simply because
folks couldn't agree on what should or shouldn't be an error in the
language.

If something is definitively wrong, then it should be an error. If it's not
definitively wrong, then the compiler shouldn't say anything about it, and
it should be left up to a linter tool of some kind like dcd.



Warnings ARE a lint tool. The only reason people have gotten the idea 
they're basically toggleable errors is because of the horrid mess that 
is C/C++, where it's common practice to permit things that no sane 
language would ever even CONSIDER not making a big, giant flashing 
sirens-blazing error (thus necessitating, at very least, a warning). 
Hell, even the actual lint tools in C/C++ land spit out tons of stuff 
that should be errors.


Summary: Warning are not bad. The C/C++ approach to warnings is bad, and 
had corrupted millions of programmer's minds.

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Tuesday, 25 September 2018 at 14:15:32 UTC, Dominikus Dittes 
Scherkl wrote:
On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports

Two problems have arisen.

First:

import std.stdio;

void foo(T)() { writeln("Hello World"); }

foo.d: Warning: unused import

To be fair, it's not *wrong*: if you remove the import, the 
module itself compiles just fine. In any case, it's trivial to 
instead move the import into the template.


The real problem is this:

import std.format;

class TestException(T) : FormatException { }

Now I can't move the import inside the template, because it's 
needed at the point of instantiation, but not inside the 
template scope *per se*.


I could require the class to be written as

template TestException(T) {
  import std.format;
  class TestException : FormatException { }
}

but that's kind of terrible.

I've been working around this for now, with import std.format 
: FormatException, but I'm not really happy with it.


Any ideas?


Doesn't the "from" idiom work?
I'm not sure if it is allowed at the template declaration

template from(string moduleName)
{
  mixin("import from = " ~ moduleName ~ ";");
}

class TestException(T) from!"std.format".FormatException
 : FormatException
{
}


class TestException(T) : from!"std.format".FormatException?

That should work, but it's kind of a big step. In any case, I'll 
never get a weird hacky template like that through code review :)


Might as well make import an expression - class TestException(T) 
: (import std.format).FormatException. In any case, it's probably 
not viable to solve the problem that a warning has a false 
positive by introducing a workaround in the language - imo, 
that'd rather mean the warning just isn't viable.


(It's so useful, though!)

Maybe stick the info in -v or -deps?

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:14:36 UTC, Jonathan M Davis 
wrote:
If something is definitively wrong, then it should be an error. 
If it's not definitively wrong, then the compiler shouldn't say 
anything about it, and it should be left up to a linter tool of 
some kind like dcd.


- Jonathan M Davis


If that's the way D wanted to go, it shouldn't have turned itself 
into a metaprogramming monster that's completely unevaluable by 
Linter tools, *or* it should offer some way to dump a 
fixed-format lowered representation with line number information 
that tools can analyze. As it stands, it is literally impossible 
to evaluate whether an import is unused without evaluating the 
entire compile-time subset of D.

Re: Warn on unused imports?

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports

Two problems have arisen.

First:

import std.stdio;

void foo(T)() { writeln("Hello World"); }

foo.d: Warning: unused import

To be fair, it's not *wrong*: if you remove the import, the 
module itself compiles just fine. In any case, it's trivial to 
instead move the import into the template.


The real problem is this:

import std.format;

class TestException(T) : FormatException { }

Now I can't move the import inside the template, because it's 
needed at the point of instantiation, but not inside the 
template scope *per se*.


I could require the class to be written as

template TestException(T) {
  import std.format;
  class TestException : FormatException { }
}

but that's kind of terrible.

I've been working around this for now, with import std.format : 
FormatException, but I'm not really happy with it.


Any ideas?


Doesn't the "from" idiom work?
I'm not sure if it is allowed at the template declaration

template from(string moduleName)
{
  mixin("import from = " ~ moduleName ~ ";");
}

class TestException(T) from!"std.format".FormatException
 : FormatException
{
}

Re: Warn on unused imports?

[Gary Willoughby via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


Honestly, I hate these types of warnings/errors. It makes playing 
with and designing code such a chore. I hope this is opt-in.

Re: Warn on unused imports?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 25, 2018 7:03:30 AM MDT FeepingCreature via 
Digitalmars-d wrote:
> I'm playing with a branch of DMD that would warn on unused
> imports:
>
> https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unu
> sed-imports
>
> Two problems have arisen.
>
> First:
>
> import std.stdio;
>
> void foo(T)() { writeln("Hello World"); }
>
> foo.d: Warning: unused import
>
> To be fair, it's not *wrong*: if you remove the import, the
> module itself compiles just fine. In any case, it's trivial to
> instead move the import into the template.
>
> The real problem is this:
>
> import std.format;
>
> class TestException(T) : FormatException { }
>
> Now I can't move the import inside the template, because it's
> needed at the point of instantiation, but not inside the template
> scope *per se*.
>
> I could require the class to be written as
>
> template TestException(T) {
>import std.format;
>class TestException : FormatException { }
> }
>
> but that's kind of terrible.
>
> I've been working around this for now, with import std.format :
> FormatException, but I'm not really happy with it.
>
> Any ideas?

Honestly, in general, warnings are a terrible idea. Anything that's a
warning in your code has to be fixed, because it's bad practice to leave
warnings in your code, meaning that ultimately, there's not much difference
between a warning and an error. To make matters worse, there's a compiler
flag that turns warnings into errors. And when you combine that with stuff
like is(typeof(...)) and template constraints, whether you use that compiler
flag or not could actually change the resulting program. So, as it stands,
warnings are an even worse idea in D than they are in other languages.
Walter likes to talk about how warnings in C/C++ are there simply because
folks couldn't agree on what should or shouldn't be an error in the
language.

If something is definitively wrong, then it should be an error. If it's not
definitively wrong, then the compiler shouldn't say anything about it, and
it should be left up to a linter tool of some kind like dcd.

- Jonathan M Davis

Re: Warn on unused imports?

[FeepingCreature via Digitalmars-d]

On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature 
wrote:
I'm playing with a branch of DMD that would warn on unused 
imports:


[...]


For instance, I've been thinking about hiding the warning behind 
an additional flag (-wunused-imports or -wu?) so that it's 
opt-in. Would that be an acceptable approach?

Warn on unused imports?

[FeepingCreature via Digitalmars-d]

I'm playing with a branch of DMD that would warn on unused 
imports:


https://github.com/FeepingCreature/dmd/tree/feature/Issue-3507-warn-on-unused-imports

Two problems have arisen.

First:

import std.stdio;

void foo(T)() { writeln("Hello World"); }

foo.d: Warning: unused import

To be fair, it's not *wrong*: if you remove the import, the 
module itself compiles just fine. In any case, it's trivial to 
instead move the import into the template.


The real problem is this:

import std.format;

class TestException(T) : FormatException { }

Now I can't move the import inside the template, because it's 
needed at the point of instantiation, but not inside the template 
scope *per se*.


I could require the class to be written as

template TestException(T) {
  import std.format;
  class TestException : FormatException { }
}

but that's kind of terrible.

I've been working around this for now, with import std.format : 
FormatException, but I'm not really happy with it.


Any ideas?

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 17:54:30 UTC, Basile B. wrote:

On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be 
pretty straightforward, since within DMD you can access the 
AST. Alternatively, implementing DIP50 might let you do it 
outside the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


If you don't understand what's a "golem":

AlquiaDa was the golem of the CIA (in the 80's while russians 
were fighting in Afgnan). Useful until a certain point.


Useful until a certain point...


It's time for me to leave...once again alcool drives me crazy...
Latest weeks I've been ofensive against two guys: kinsley and 
lopatim...it's time for me to leave.


https://www.youtube.com/watch?v=6ixdPnLFVIo

seeya.

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside 
the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside 
the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


If you don't understand what's a "golem":

AlquiaDa was the golem of the CIA (in the 80's while russians 
were fighting in Afgnan). Useful until a certain point.


Useful until a certain point...

Re: How to warn of unused imports?

[Daniel Kozak via Digitalmars-d-learn]

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  napsáno:

> When I factor out code from my modules, it really, really often 
> leaves import statements that just sit there doing nothing, 
> making it look like my program is more complex than it is. How do 
> I get warned for leaving those, and a list of which ones I can 
> safely remove?

I dont think there is a way right now. But in a future dscanner.
https://github.com/Hackerpilot/Dscanner/issues/134

How to warn of unused imports?

[cy via Digitalmars-d-learn]

When I factor out code from my modules, it really, really often 
leaves import statements that just sit there doing nothing, 
making it look like my program is more complex than it is. How do 
I get warned for leaving those, and a list of which ones I can 
safely remove?

Re: How to warn of unused imports?

[Adam D. Ruppe via Digitalmars-d-learn]

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:
How do I get warned for leaving those, and a list of which ones 
I can safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and 
move on to the next one.

Re: How to warn of unused imports?

[Ali Çehreli via Digitalmars-d-learn]

On 02/08/2016 06:35 AM, Adam D. Ruppe wrote:

On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote:

How do I get warned for leaving those, and a list of which ones I can
safely remove?


Remove one, recompile. If it passes, leave it. If not, undo and move on
to the next one.


Similarly, I comment out all; then uncomment one by one according to 
compilation errors.


Ali

Re: How to warn of unused imports?

[cy via Digitalmars-d-learn]

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for DMD. 
I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside the 
compiler.


http://wiki.dlang.org/DIP50

Re: How to warn of unused imports?

[Basile B. via Digitalmars-d-learn]

On Monday, 8 February 2016 at 08:50:17 UTC, Daniel Kozak wrote:

V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  
napsáno:


When I factor out code from my modules, it really, really 
often leaves import statements that just sit there doing 
nothing, making it look like my program is more complex than 
it is. How do I get warned for leaving those, and a list of 
which ones I can safely remove?


I dont think there is a way right now. But in a future 
dscanner. https://github.com/Hackerpilot/Dscanner/issues/134


I don't think that Dscanner will be able to do this soon. Its 
scope is limited to a single module, it's not like DCD, which 
works with the imports and which is able to look-up elsewhere.


For example you'll see this if you try to make an analyzer that 
produces warnings for signed & unsigned comparison. It impossible 
without a bit of semantic (ref: 
https://github.com/Hackerpilot/Dscanner/issues/204).


Otherwise, it sounds like a decent enhancement request for DMD. I 
know other compilers who do this warning.