www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Warn on unused imports?

reply FeepingCreature <feepingcreature gmail.com> writes:
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?
Sep 25 2018
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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?
Sep 25 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 25 2018
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
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.
Sep 25 2018
parent reply Jacob Carlborg <doob me.com> writes:
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
Sep 25 2018
parent reply FeepingCreature <feepingcreature gmail.com> writes:
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.
Sep 26 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
Sep 26 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Sep 26 2018
parent Jacob Carlborg <doob me.com> writes:
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
Sep 27 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 25 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 25 2018
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
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 .
Sep 26 2018
prev sibling next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
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.
Sep 26 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 26 2018
next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
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:
```
   -d                silently 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.
Sep 26 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 26, 2018 4:46:23 AM MDT Laurent Tréguier via 
Digitalmars-d wrote:

  From dmd's help:
 ```
    -d                silently 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
Sep 26 2018
prev sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
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.
Sep 28 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 28 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Oct 01 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 02 2018
prev sibling next sibling parent Gary Willoughby <dev nomad.uk.net> writes:
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.
Sep 25 2018
prev sibling next sibling parent reply Dominikus Dittes Scherkl <dominikus.scherkl continental-corporation.com> writes:
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
{
}
Sep 25 2018
parent reply FeepingCreature <feepingcreature gmail.com> writes:
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?
Sep 25 2018
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature 
wrote:

 Maybe stick the info in -v or -deps?


Actually, -deps is the perfect place for it. It needs to 
recursively evaluate modules anyways, so it'll see an import even 
if it was only used from a template. And it doesn't spam up 
warnings, and the -deps info is made to be extensible anyways.

Great! I'll port it to there.
Sep 25 2018
prev sibling parent Dominikus Dittes Scherkl <dominikus.scherkl continental-corporation.com> writes:
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.
Sep 26 2018
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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...
Sep 26 2018
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
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.
Sep 26 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
Sep 26 2018
parent reply FeepingCreature <feepingcreature gmail.com> writes:
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.
Sep 30 2018
parent FeepingCreature <feepingcreature gmail.com> writes:
Typo: to not* be a warning
Sep 30 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 27 2018
parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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?
Oct 03 2018
parent reply Dennis <dkorpel gmail.com> writes:
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 

- 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.
Oct 03 2018
parent JN <666total wp.pl> writes:
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 

 - 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.
Oct 05 2018
prev sibling next sibling parent reply Anonymouse <asdf asdf.net> writes:
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.
Sep 26 2018
next sibling parent drug <drug2004 bk.ru> writes:
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.
Sep 26 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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!"
Oct 04 2018
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Oct 05 2018
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
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!
Sep 26 2018
prev sibling parent reply Martin <martin.brzenska googlemail.com> writes:
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 [...]


Hi, i was searching for such a functionality in D and this thread 
is the most recent result on google. So, i would like to know if 
there is progress on the topic?
Jan 31 2021
parent reply a11e99z <black80 bk.ru> writes:
suggestion: implicit import at same line as using

auto result = std.algorithm:find!blahblah(args);

1) its likes to/same as
import std.algorithm : find; with next using
but usuall it looks ugly:
{
   import one.stuff : some;
   import another.stuff : other;

   then goes some code;
   and then using here;
   so when u delete code - u left imports

2) u can use it for classes too
class Derived : some.module.B:Base { // no need import before

3) usually u import some entity for just one using so when u will 
delete this using u will delete unnecessary import too. no need 
separate line for it

easy to implement (imo), good looks as D-stuff, solves problem
Jan 31 2021
next sibling parent reply a11e99z <black80 bk.ru> writes:
On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 suggestion: implicit import at same line as using

 auto result = std.algorithm:find!blahblah(args);


note: colon as separator for module part and other
u can still use ufcs and usual magic
module part just says where to look object or method
Jan 31 2021
parent a11e99z <black80 bk.ru> writes:
On Sunday, 31 January 2021 at 19:22:43 UTC, a11e99z wrote:

 On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 suggestion: implicit import at same line as using

 auto result = std.algorithm:find!blahblah(args);


 note: colon as separator for module part and other
 u can still use ufcs and usual magic
 module part just says where to look object or method


OK, u saw implementation for classes with 2 colons
class Derived : some.module:Base {
its simple sample but can be more difficult that uses colon too.
     at here 1st colon means inheritance

u can implement it as
class Derived : some.module Base { //  
i dont care
but "inplace import with using" looks more preferably
Jan 31 2021
prev sibling next sibling parent a11e99z <black80 bk.ru> writes:
On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 suggestion: implicit import at same line as using

 auto result = std.algorithm:find!blahblah(args);


4) and u can use different find methods from diff modules without 
aliases that adds more stupid lines
Jan 31 2021
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 suggestion: implicit import at same line as using

 auto result = std.algorithm:find!blahblah(args);


We have that, remember

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

void main()
{
     from!"std.stdio".writeln("check 
https://dlang.org/blog/2017/02/13/a-new-import-idiom/");
}
---
Feb 02 2021
next sibling parent Martin <martin.brzenska googlemail.com> writes:
On Tuesday, 2 February 2021 at 08:35:40 UTC, Basile B. wrote:

 $suggestion


On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 $suggestion


Thanks for the answers, i take it as a "no" ;)
Feb 02 2021
prev sibling parent a11e99z <black80 bk.ru> writes:
On Tuesday, 2 February 2021 at 08:35:40 UTC, Basile B. wrote:

 On Sunday, 31 January 2021 at 19:18:04 UTC, a11e99z wrote:

 suggestion: implicit import at same line as using

 auto result = std.algorithm:find!blahblah(args);


 We have that, remember

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

 void main()
 {
     from!"std.stdio".writeln("check 
 https://dlang.org/blog/2017/02/13/a-new-import-idiom/");
 }
 ---


I didn't know that.
yep, I checked, its working.
but IntelliSense cannot help with strings.
Feb 03 2021