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

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.

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 .

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.

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

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.

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

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.

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.

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!