I just submitted a PR [1] that catagorizes warnings, such that you can do something like this:
dmd -w -Wno-not-reachable
which would error on any warning except the "statement not reachable" warnings (it completely disables that warning).

The motivation for the selective disabling/enabling of warnings was a recent discussion in the Learn forum [2].

Please read about it in detail in the first message of the PR [1].

- Johan

[1]  https://github.com/D-Programming-Language/dmd/pull/5592
[2]  http://forum.dlang.org/thread/baupegcfvumouhgauetk@forum.dlang.org

On Monday, 28 March 2016 at 16:21:15 UTC, Johan Engelen wrote:
> I just submitted a PR [1] that catagorizes warnings, such that you can do something like this:
> dmd -w -Wno-not-reachable
> which would error on any warning except the "statement not reachable" warnings (it completely disables that warning).
>
> The motivation for the selective disabling/enabling of warnings was a recent discussion in the Learn forum [2].
>
> Please read about it in detail in the first message of the PR [1].
>
> - Johan
>
> [1]  https://github.com/D-Programming-Language/dmd/pull/5592
> [2]  http://forum.dlang.org/thread/baupegcfvumouhgauetk@forum.dlang.org

I think warnings being part of the compiler is a mistake. I don't think they will ever be removed, so I think this is a good compromise.

The only reason compilers have warnings in them is because C++ needs an entire compiler to warn you about potential problems, and it has since become tradition for that feature to be included. We can just as easily rely on dscanner for this kind of thing and simplify the compiler.

On 3/28/16 12:47 PM, Jack Stouffer wrote:
> On Monday, 28 March 2016 at 16:21:15 UTC, Johan Engelen wrote:
>> I just submitted a PR [1] that catagorizes warnings, such that you can
>> do something like this:
>> dmd -w -Wno-not-reachable
>> which would error on any warning except the "statement not reachable"
>> warnings (it completely disables that warning).
>>
>> The motivation for the selective disabling/enabling of warnings was a
>> recent discussion in the Learn forum [2].
>>
>> Please read about it in detail in the first message of the PR [1].
>>
>> - Johan
>>
>> [1]  https://github.com/D-Programming-Language/dmd/pull/5592
>> [2] http://forum.dlang.org/thread/baupegcfvumouhgauetk@forum.dlang.org
>
> I think warnings being part of the compiler is a mistake. I don't think
> they will ever be removed, so I think this is a good compromise.
>
> The only reason compilers have warnings in them is because C++ needs an
> entire compiler to warn you about potential problems, and it has since
> become tradition for that feature to be included. We can just as easily
> rely on dscanner for this kind of thing and simplify the compiler.

Warnings can be an important part of the deprecation process. The next release of the compiler will illustrate that.

-Steve

On Monday, 28 March 2016 at 17:05:46 UTC, Steven Schveighoffer wrote:
> Warnings can be an important part of the deprecation process. The next release of the compiler will illustrate that.
>
> -Steve

But the import issues weren't solved with warnings, they went strait to deprecation.

And I'd argue that warnings are an unnecessary step in the deprecation process. IMO the deprecation -> undocumented -> removed cycle for Phobos works well. Adding another step to it needlessly delays the inevitable (how long has array.sort been a warning?), and I don't see why the same process won't work for DMD.

On 3/28/16 1:11 PM, Jack Stouffer wrote:
> On Monday, 28 March 2016 at 17:05:46 UTC, Steven Schveighoffer wrote:
>> Warnings can be an important part of the deprecation process. The next
>> release of the compiler will illustrate that.
>>
>> -Steve
>
> But the import issues weren't solved with warnings, they went strait to
> deprecation.

No, there is a warning for using a selective import and using a fully qualified name from that module.

> And I'd argue that warnings are an unnecessary step in the deprecation
> process. IMO the deprecation -> undocumented -> removed cycle for Phobos
> works well. Adding another step to it needlessly delays the inevitable
> (how long has array.sort been a warning?), and I don't see why the same
> process won't work for DMD.

The deprecation stage is the warning stage. Note that the two other compilers take some time to catch up. If you can't disable the new behavior somehow, then you have projects that will compile only for dmd, or only for the other compilers. There needs to be some kind of transition period where you can write code that is compatible with all in some way or another.

-Steve

On Monday, 28 March 2016 at 17:39:02 UTC, Steven Schveighoffer wrote:
> The deprecation stage is the warning stage. Note that the two other compilers take some time to catch up. If you can't disable the new behavior somehow, then you have projects that will compile only for dmd, or only for the other compilers. There needs to be some kind of transition period where you can write code that is compatible with all in some way or another.

A large percentage of people, especially since this is the default for dub, treat warnings as errors. Warnings should NOT be part of a deprecation cycle, that's what deprecations are for.

Warnings are not the purview of compilers (or shouldn't be anyway).

On Monday, 28 March 2016 at 16:47:53 UTC, Jack Stouffer wrote:
> The only reason compilers have warnings in them is because C++ needs an entire compiler to warn you about potential problems, and it has since become tradition for that feature to be included. We can just as easily rely on dscanner for this kind of thing and simplify the compiler.

A lot of warnings in D require a full compiler. Did you forget that CTFE + string mixins exist?

On Monday, 28 March 2016 at 16:21:15 UTC, Johan Engelen wrote:
> I just submitted a PR [1] that catagorizes warnings, such that you can do something like this:
> dmd -w -Wno-not-reachable
> which would error on any warning except the "statement not reachable" warnings (it completely disables that warning).
>
> The motivation for the selective disabling/enabling of warnings was a recent discussion in the Learn forum [2].

Glad tsbockman put you on the tracks :)

On Monday, 28 March 2016 at 18:47:15 UTC, Jack Stouffer wrote:
> But the import issues weren't solved with warnings, they went strait to deprecation.
>
> And I'd argue that warnings are an unnecessary step in the deprecation process. IMO the deprecation -> undocumented -> removed cycle for Phobos works well. Adding another step to it needlessly delays the inevitable (how long has array.sort been a warning?), and I don't see why the same process won't work for DMD.

A language change has much more impact than a Phobos change. Plus, Phobos cannot issue warnings.

The deprecation process needs multiple phases:
- One to prevent new code from using this, and spreading the word
- One to make it fail by default but still allow the end user to keep old code working
- And at the end you finally kill it

A warning is an indication that something is probably wrong with your code (if you exclude statement not reachable, which has some false positive, but could still prevent bugs like "goto fail").
A deprecation is not a problem. It's a note left to the user. I've yet to see a repo where deprecation as error is enabled.

On 03/28/2016 08:05 PM, Steven Schveighoffer wrote:
> Warnings can be an important part of the deprecation process. The next release of the compiler will illustrate that.

No. Deciding that warnings have any relation with deprecation process was huge mistake and, as far as I know, it is going to be fixed. Though it can easily be that something new and annoying has slipped into next release too.

On 03/28/2016 07:21 PM, Johan Engelen wrote:
> I just submitted a PR [1] that catagorizes warnings, such that you can
> do something like this:
> dmd -w -Wno-not-reachable
> which would error on any warning except the "statement not reachable"
> warnings (it completely disables that warning).
> 
> The motivation for the selective disabling/enabling of warnings was a recent discussion in the Learn forum [2].
> 
> Please read about it in detail in the first message of the PR [1].
> 
> - Johan
> 
> [1]  https://github.com/D-Programming-Language/dmd/pull/5592
> [2]  http://forum.dlang.org/thread/baupegcfvumouhgauetk@forum.dlang.org

Sadly, this isn't very useful. If there is one legitimate use of code warned about one wants to disable that specific place and not all warning of that kind in whole program. Which means it has to be controlled by some sort of pragma.