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 Kozák:
 

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