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.

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

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.

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.

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.

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.

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.

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

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.

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