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