www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecations: Any reason left for warning stage?

reply "David Nadlinger" <code klickverbot.at> writes:
As Walter mentioned in a recent pull request discussion [1], the 
first formal deprecation protocol we came up with for language 
changes looked something like this:

1. remove from documentation
2. warning
3. deprecation
4. error

(The "remove from documentation" step is a bit questionable, but 
that's not my point here.)

However, in the meantime deprecations were changed to be 
informational by default. You now need to explicitly need to pass 
-de to turn them into errors that halt compilation. Thus, I think 
we should simply get rid of the warning step, just like we (de 
facto) eliminated the "scheduled for deprecation" stage from the 
Phobos process.

Thoughts?

Best,
David


[1] 
https://github.com/D-Programming-Language/dmd/pull/4021#issuecomment-56758916
Sep 26 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 04:15:40PM +0000, David Nadlinger via Digitalmars-d
wrote:
 As Walter mentioned in a recent pull request discussion [1], the first
 formal deprecation protocol we came up with for language changes
 looked something like this:
 
 1. remove from documentation
 2. warning
 3. deprecation
 4. error
 
 (The "remove from documentation" step is a bit questionable, but
 that's not my point here.)
 
 However, in the meantime deprecations were changed to be informational
 by default. You now need to explicitly need to pass -de to turn them
 into errors that halt compilation. Thus, I think we should simply get
 rid of the warning step, just like we (de facto) eliminated the
 "scheduled for deprecation" stage from the Phobos process.
 
 Thoughts?
[...] I think the warning stage is still necessary. Users need to be informed well ahead of time that something is going to be deprecated, before it starts breaking their builds (which, according to recommended usage, shouldn't be compiling with -d). We'll get a lot fewer angry users this way. Recently there was a case of a deprecation that broke the default build of a large project, and the author was surprised (and not very happy) to learn that something had been "suddenly" deprecated -- because the deprecation warnings wouldn't even show up unless you specifically compile with -dw. I think now -dw has been made default, which is the right step forwards IMO, so it should be kept that way. T -- I'm still trying to find a pun for "punishment"...
Sep 26 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 26 September 2014 at 16:31:52 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 I think the warning stage is still necessary. Users need to be 
 informed
 well ahead of time that something is going to be deprecated, 
 before it
 starts breaking their builds (which, according to recommended 
 usage,
 shouldn't be compiling with -d). We'll get a lot fewer angry 
 users this way.
Wait, what? I was talking specifically about the stage as a capital-W-warning, i.e. something that shows up only when the user specifies -w or -wi. Deprecations are informational by default now, unless you explicitly specify -de. As far as I can see having deprecation messages as Warnings first actually leads to *more* build breakage (as many more people are building with -w than with -de) and less time for adapting code before it is made an error (because -w/-wi is not the default). Thus, I don't see any justification left for making deprecation messages Warnings first. David
Sep 29 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"David Nadlinger"  wrote in message 
news:hqjjujxwydtzpgfcnqax forum.dlang.org...

 As far as I can see having deprecation messages as Warnings first actually 
 leads to *more* build breakage (as many more people are building with -w 
 than with -de) and less time for adapting code before it is made an error 
 (because -w/-wi is not the default).
But that's a good thing - the people who get their code broken are the people who are asking for it with '-w'.
Sep 29 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 29 September 2014 at 15:13:28 UTC, Daniel Murphy wrote:
 But that's a good thing - the people who get their code broken 
 are the people who are asking for it with '-w'.
I don't think there is much merit to this argument. First, it's not like the ability to make diagnostics halt the build is something specific to Warnings. Just pass -de and use of deprecated symbols will halt compilation too. (Actually, not passing -de would lead to a funny error(Warning)->warning(Deprecation)->error(Error) progression right now.) Second, if I'm using "-w", I'm typically interested in errors if I write fishy code, not because some third-party library I just updated made a small change to its API. I don't see where the advantage would be in conflating the two things. David
Oct 04 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"David Nadlinger"  wrote in message 
news:tsxbhkdfwilqjpqekogq forum.dlang.org...

 Second, if I'm using "-w", I'm typically interested in errors if I write 
 fishy code, not because some third-party library I just updated made a 
 small change to its API. I don't see where the advantage would be in 
 conflating the two things.
You don't get 'warning' deprecations from third-party code, you get them from the compiler when you use a feature that is on its way to being deprecated. Usually because it's fishy.
Oct 05 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 Oct 2014 08:10, "Daniel Murphy via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 "David Nadlinger"  wrote in message
news:tsxbhkdfwilqjpqekogq forum.dlang.org...
 Second, if I'm using "-w", I'm typically interested in errors if I write
fishy code, not because some third-party library I just updated made a small change to its API. I don't see where the advantage would be in conflating the two things.
 You don't get 'warning' deprecations from third-party code, you get them
from the compiler when you use a feature that is on its way to being deprecated. Usually because it's fishy. The 'deprecated' for all intents and purposes might as well emit a warning when you try to use deprecated features of third party code. Didn't you Phobos devs have a hardDeprecation message too that would force an error?
Oct 05 2014
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 Oct 2014 22:30, "David Nadlinger via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 On Monday, 29 September 2014 at 15:13:28 UTC, Daniel Murphy wrote:
 But that's a good thing - the people who get their code broken are the
people who are asking for it with '-w'.
 I don't think there is much merit to this argument.

 First, it's not like the ability to make diagnostics halt the build is
something specific to Warnings. Just pass -de and use of deprecated symbols will halt compilation too. (Actually, not passing -de would lead to a funny error(Warning)->warning(Deprecation)->error(Error) progression right now.)

One reason why on GDC I removed the distinction between -w and -de, there
are now three GCC-style switches: -Wall (-wi), -Wdeprecated (-d), and
-Werror (-w, -de). All of which are off by default.

Iain.
Oct 05 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 09/29/2014 11:58 AM, David Nadlinger wrote:
 As far as I can see having deprecation messages as Warnings first
 actually leads to *more* build breakage (as many more people are
 building with -w than with -de) and less time for adapting code before
 it is made an error (because -w/-wi is not the default).
I agree with this. Warnings are an orthogonal to deprecation and the current practice causes quite some grief.
Sep 29 2014
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/26/14 12:15 PM, David Nadlinger wrote:
 As Walter mentioned in a recent pull request discussion [1], the first
 formal deprecation protocol we came up with for language changes looked
 something like this:

 1. remove from documentation
 2. warning
 3. deprecation
 4. error

 (The "remove from documentation" step is a bit questionable, but that's
 not my point here.)

 However, in the meantime deprecations were changed to be informational
 by default. You now need to explicitly need to pass -de to turn them
 into errors that halt compilation. Thus, I think we should simply get
 rid of the warning step, just like we (de facto) eliminated the
 "scheduled for deprecation" stage from the Phobos process.

 Thoughts?
Case against: https://github.com/D-Programming-Language/phobos/pull/2254#issuecomment-52764718 -Steve
Sep 26 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Friday, 26 September 2014 at 18:38:43 UTC, Steven 
Schveighoffer wrote:
 Case against: 
 https://github.com/D-Programming-Language/phobos/pull/2254#issuecomment-52764718
I don't think this is relevant for this discussion at all. Vladimir asked for advance notice in terms of docs before anything changes about the actual implementation. Making stuff a Warning addresses this just as much or as little as making it a Deprecation does. To put it differently: Were the issue in question a language change (under the current deprecation process), Vladimir would have complained all the same about DMD spewing Warning messages. You might even be able to construe it as an argument in favor of dropping the Warning stage – at least deprecation warnings can easily be filtered out without hiding potentially useful Warnings that might indicate something wrong with your code. David
Sep 29 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 29 September 2014 at 10:15:07 UTC, David Nadlinger 
wrote:
 On Friday, 26 September 2014 at 18:38:43 UTC, Steven 
 Schveighoffer wrote:
 Case against: 
 https://github.com/D-Programming-Language/phobos/pull/2254#issuecomment-52764718
I don't think this is relevant for this discussion at all. Vladimir asked for advance notice in terms of docs before anything changes about the actual implementation. Making stuff a Warning addresses this just as much or as little as making it a Deprecation does.
To clarify, what I'm really asking is a one-release-window in which both the old and new way to do something works without any warnings or deprecated messages. This is so I'm not forced to update the compilers or all my machines simultaneously. This is especially important considering LDC/GDC usually lag one frontend version behind: if you use bleeding-edge DMD for development, you can't enable all the deprecation/warning messages (which should be enabled during development of new code) without either breaking GDC/LDC/DMD v. N-1 compatibility, or dealing with the spam. How the change is reflected in the documentation (kept, scheduled for deprecation, or removed), is not very important to me personally.
 To put it differently: Were the issue in question a language 
 change (under the current deprecation process), Vladimir would 
 have complained all the same about DMD spewing Warning messages.
All's good as long as there exists syntax that is silently accepted in both version N and N+1.
 You might even be able to construe it as an argument in favor 
 of dropping the Warning stage – at least deprecation warnings 
 can easily be filtered out without hiding potentially useful 
 Warnings that might indicate something wrong with your code.
This would be more applicable if deprecation messages included a version number indicating when a certain feature was deprecated.
Sep 29 2014
prev sibling next sibling parent reply =?utf-8?Q?Daniel_Koz=C3=A1k?= via Digitalmars-d writes:
The only one and right solution is print warning message by default

----- P=C5=AFvodn=C3=AD zpr=C3=A1va -----
Od:"David Nadlinger via Digitalmars-d" <digitalmars-d puremagic.com>
Odesl=C3=A1no:=E2=80=8E26. =E2=80=8E9. =E2=80=8E2014 18:20
Komu:"digitalmars-d puremagic.com" <digitalmars-d puremagic.com>
P=C5=99edm=C4=9Bt:Deprecations: Any reason left for warning stage?

As Walter mentioned in a recent pull request discussion [1], the=20
first formal deprecation protocol we came up with for language=20
changes looked something like this:

1. remove from documentation
2. warning
3. deprecation
4. error

(The "remove from documentation" step is a bit questionable, but=20
that's not my point here.)

However, in the meantime deprecations were changed to be=20
informational by default. You now need to explicitly need to pass=20
-de to turn them into errors that halt compilation. Thus, I think=20
we should simply get rid of the warning step, just like we (de=20
facto) eliminated the "scheduled for deprecation" stage from the=20
Phobos process.

Thoughts?

Best,
David


[1]=20
https://github.com/D-Programming-Language/dmd/pull/4021#issuecomment-567589=
16
Sep 26 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Kozák:

 The only one and right solution is print warning message by 
 default
I am asking for this since some years. Bye, bearophile
Sep 26 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 26, 2014 at 09:16:50PM +0000, bearophile via Digitalmars-d wrote:
 Daniel Kozk:
 
The only one and right solution is print warning message by default
I am asking for this since some years.
[...] In git HEAD, dmd now allows use of deprecated features and displays a warning by default. Only if you compile with -de, it will become an error. T -- "I'm not childish; I'm just in touch with the child within!" - RL
Sep 26 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 In git HEAD, dmd now allows use of deprecated features and 
 displays a warning by default.
I meant I'd like by default all warnings to be shown :-) Bye, bearophile
Sep 26 2014
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Friday, 26 September 2014 at 21:13:14 UTC, Daniel Kozák via 
Digitalmars-d wrote:
 The only one and right solution is print warning message by 
 default
This is actually what is done for deprecations already. -dw is the default. We just currently don't use them this way, for whatever reasons. David
Sep 29 2014
prev sibling next sibling parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2014-09-27 1:15 GMT+09:00 David Nadlinger via Digitalmars-d <
digitalmars-d puremagic.com>:

 As Walter mentioned in a recent pull request discussion [1], the first
 formal deprecation protocol we came up with for language changes looked
 something like this:

 1. remove from documentation
 2. warning
 3. deprecation
 4. error

 (The "remove from documentation" step is a bit questionable, but that's
 not my point here.)

 However, in the meantime deprecations were changed to be informational by
 default. You now need to explicitly need to pass -de to turn them into
 errors that halt compilation. Thus, I think we should simply get rid of the
 warning step, just like we (de facto) eliminated the "scheduled for
 deprecation" stage from the Phobos process.

 Thoughts?
I agree that the current warning stage for the deprecated features is useless. Kenji Hara
Sep 30 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, September 26, 2014 23:12:47 Daniel Kozák via Digitalmars-d wrote:
 The only one and right solution is print warning message by default

 ----- Původní zpráva -----
 Od:"David Nadlinger via Digitalmars-d" <digitalmars-d puremagic.com>
 Odesláno:‎26. ‎9. ‎2014 18:20
 Komu:"digitalmars-d puremagic.com" <digitalmars-d puremagic.com>
 Předmět:Deprecations: Any reason left for warning stage?

 As Walter mentioned in a recent pull request discussion [1], the
 first formal deprecation protocol we came up with for language
 changes looked something like this:

 1. remove from documentation
 2. warning
 3. deprecation
 4. error
This makes no sense now. Realistically, warning is more restrictive than deprecation at this point, because -w makes warnings errors, and the equivalent for deprecated is probably used much less (certainly, it's much newer and therefore less likely to be used). So, step 2 to 3 is essentially making things _less_ restrictive. And really, warnings have nothing to do with deprecation. Using them made sense when there was no way to print deprecation messages without having them be an error, but now that deprecation messages are just messages normally and do not alter compilation at all, using warnings for deprecation makes no sense at all. - Jonathan M Davis
Oct 05 2014