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.

Typo: to not* be a warning

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.

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

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.

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

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.

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

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.

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?