On Tuesday, 29 March 2016 at 04:35:11 UTC, Dicebot wrote:
>
> 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.

for which you would need categorization of warnings.

On Tuesday, 29 March 2016 at 08:13:59 UTC, Johan Engelen wrote:
> On Tuesday, 29 March 2016 at 04:35:11 UTC, Dicebot wrote:
>>
>> 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.
>
> for which you would need categorization of warnings.

Not necessarily. "Ignore any warning in next statement" would work in practice too. Though categorization is indeed useful for clean separation - as part of such pragma.

On 3/29/16 12:29 AM, Dicebot wrote:
> 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.
>

The next release will have a deprecation warning about selective imports that mistakenly allow usage of FQN. You will see most likely. Phobos had thousands of them.

-Steve

On Tuesday, 29 March 2016 at 12:21:59 UTC, Steven Schveighoffer wrote:
> The next release will have a deprecation warning about selective imports that mistakenly allow usage of FQN. You will see most likely. Phobos had thousands of them.
>
> -Steve

Deprecation or a warning? It must be deprecation (as in, "don't fail on -w"). If it isn't, probably it is time to raise some critical bugzilla reports.

On 3/29/16 8:24 AM, Dicebot wrote:
> On Tuesday, 29 March 2016 at 12:21:59 UTC, Steven Schveighoffer wrote:
>> The next release will have a deprecation warning about selective
>> imports that mistakenly allow usage of FQN. You will see most likely.
>> Phobos had thousands of them.
>>
>
> Deprecation or a warning? It must be deprecation (as in, "don't fail on
> -w"). If it isn't, probably it is time to raise some critical bugzilla
> reports.

I think it might be simply deprecation. I can't remember.

Tested:

Yes, it is a deprecation, not a warning (compilation succeeds on -w). I stand corrected!

This is in essence, still a warning. Just not one that fails compilation. It makes build messages from large projects basically unreadable.

-Steve

On 03/29/2016 03:34 PM, Steven Schveighoffer wrote:
> I think it might be simply deprecation. I can't remember.
> 
> Tested:
> 
> Yes, it is a deprecation, not a warning (compilation succeeds on -w). I
> stand corrected!

Thanks, no need for me to panic in that case :)

> This is in essence, still a warning. Just not one that fails compilation. It makes build messages from large projects basically unreadable.

There is essential difference. Warning indicates some error-prone code and most projects do want to build with warnings enabled by default. Deprecation is simply early indication of requested change and it is OK for any projects to take weeks and months to clean up deprecatations as the time allows.

The fact that deprecations don't break compilation by default is crucial in dub ecosystem as otherwise each compiler release could make your dub dependencies unusable until their maintainers make new release with fixes. Deprecations provide that transitional step.

Also you can disable deprecation messages completely with `-d`.

On Tuesday, 29 March 2016 at 04:29:52 UTC, Dicebot wrote:
> 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.

I was very surprised I had to catagorize some warnings as "soon-deprecated". Let's get the remaining two "warnings" to deprecated status asap then?
https://dlang.org/deprecate.html
(they are warnings from 2.067)

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 categorizing warnings could be useful, but must point out that for the "statement not reachable" problem (DMD 14835), specifically, this is not really a good long term solution.

The reason is that Phobos itself contains many statements which are "not reachable" according to the compiler's current flawed definition. (They aren't detected as such only because the constant folding and value range propagation capabilities are rather weak currently.)

If Phobos requires a -Wno-not-reachable switch to compile, then anything that uses Phobos will likely require the switch, also. At that point, it makes more sense to just fix/remove the warning, rather than selectively disabling it for some projects.