• Johan Engelen (12/12) Mar 28 2016 I just submitted a PR [1] that catagorizes warnings, such that
• Jack Stouffer (9/22) Mar 28 2016 I think warnings being part of the compiler is a mistake. I don't
• Steven Schveighoffer (4/26) Mar 28 2016 Warnings can be an important part of the deprecation process. The next
• Jack Stouffer (10/13) Mar 28 2016 But the import issues weren't solved with warnings, they went
• Steven Schveighoffer (10/22) Mar 28 2016 No, there is a warning for using a selective import and using a fully
• Jack Stouffer (7/13) Mar 28 2016 A large percentage of people, especially since this is the
• Mathias Lang (15/30) Mar 28 2016 Glad tsbockman put you on the tracks :)
• Dicebot (5/7) Mar 28 2016 No. Deciding that warnings have any relation with deprecation process
• Steven Schveighoffer (5/12) Mar 29 2016 The next release will have a deprecation warning about selective imports...
• Dicebot (5/9) Mar 29 2016 Deprecation or a warning? It must be deprecation (as in, "don't
• Steven Schveighoffer (9/17) Mar 29 2016 I think it might be simply deprecation. I can't remember.
• Dicebot (12/21) Mar 29 2016 There is essential difference. Warning indicates some error-prone code
• Johan Engelen (6/13) Mar 29 2016 I was very surprised I had to catagorize some warnings as
• Brian Schott (3/8) Mar 28 2016 A lot of warnings in D require a full compiler. Did you forget
• Dicebot (5/20) Mar 28 2016 Sadly, this isn't very useful. If there is one legitimate use of code
• Johan Engelen (2/6) Mar 29 2016 for which you would need categorization of warnings.
• Dicebot (4/11) Mar 29 2016 Not necessarily. "Ignore any warning in next statement" would
• tsbockman (13/26) Mar 29 2016 I think categorizing warnings could be useful, but must point out

Johan Engelen <j j.nl> writes:

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

Jack Stouffer <jack jackstouffer.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jack Stouffer <jack jackstouffer.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jack Stouffer <jack jackstouffer.com> writes:

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

Mathias Lang <mathias.lang sociomantic.com> writes:

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.

Dicebot <public dicebot.lv> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Dicebot <public dicebot.lv> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Dicebot <public dicebot.lv> writes:

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

Johan Engelen <j j.nl> writes:

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)

Brian Schott <briancschott gmail.com> writes:

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?

Dicebot <public dicebot.lv> writes:

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.

Johan Engelen <j j.nl> writes:

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.

Dicebot <public dicebot.lv> writes:

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.

tsbockman <thomas.bockman gmail.com> writes:

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.