Deprecations: Any reason left for warning stage?

[David Nadlinger via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

As Walter mentioned in a recent pull request discussion [1], the first
formal deprecation protocol we came up with for language changes
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

[Steven Schveighoffer via Digitalmars-d]

As Walter mentioned in a recent pull request discussion [1], the first
formal deprecation protocol we came up with for language changes looked
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

[David Nadlinger via Digitalmars-d]

On Friday, 26 September 2014 at 18:38:43 UTC, Steven

Post by Steven Schveighoffer via Digitalmars-d
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

[Vladimir Panteleev via Digitalmars-d]

On Monday, 29 September 2014 at 10:15:07 UTC, David Nadlinger

Post by David Nadlinger via Digitalmars-d
On Friday, 26 September 2014 at 18:38:43 UTC, Steven

Post by Steven Schveighoffer via Digitalmars-d
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.

Post by David Nadlinger via Digitalmars-d
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.

Post by David Nadlinger via Digitalmars-d
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.

[Daniel Kozák via Digitalmars-d]

The only one and right solution is print warning message by default

----- Původní zpráva -----
Od:"David Nadlinger via Digitalmars-d" <digitalmars-d at puremagic.com>
Odesláno:‎26. ‎9. ‎2014 18:20
Komu:"digitalmars-d at puremagic.com" <digitalmars-d at 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

(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140926/702b745d/attachment.html>

[Jonathan M Davis via Digitalmars-d]

Post by Daniel Kozák via Digitalmars-d
The only one and right solution is print warning message by default
----- Původní zpráva -----
Od:"David Nadlinger via Digitalmars-d" <digitalmars-d at puremagic.com>
Odesláno:‎26. ‎9. ‎2014 18:20
Komu:"digitalmars-d at puremagic.com" <digitalmars-d at 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
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

[bearophile via Digitalmars-d]

Post by Daniel Kozák via Digitalmars-d
The only one and right solution is print warning message by
default

I am asking for this since some years.

Bye,
bearophile

[H. S. Teoh via Digitalmars-d]

Post by bearophile via Digitalmars-d

Post by Daniel Kozák via Digitalmars-d
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

[bearophile via Digitalmars-d]

Post by H. S. Teoh via Digitalmars-d
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

[David Nadlinger via Digitalmars-d]

On Friday, 26 September 2014 at 16:31:52 UTC, H. S. Teoh via

Post by H. S. Teoh via Digitalmars-d
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

[Daniel Murphy via Digitalmars-d]

"David Nadlinger" wrote in message

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

[David Nadlinger via Digitalmars-d]

Post by Daniel Murphy via Digitalmars-d
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

[Daniel Murphy via Digitalmars-d]

"David Nadlinger" wrote in message

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.

[Iain Buclaw via Digitalmars-d]

On 5 Oct 2014 08:10, "Daniel Murphy via Digitalmars-d" <

Post by Daniel Murphy via Digitalmars-d
"David Nadlinger" wrote in message

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.

Post by Daniel Murphy via Digitalmars-d
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141005/2688fa76/attachment.html>

[Iain Buclaw via Digitalmars-d]

On 4 Oct 2014 22:30, "David Nadlinger via Digitalmars-d" <

Post by David Nadlinger via Digitalmars-d

Post by Daniel Murphy via Digitalmars-d
But that's a good thing - the people who get their code broken are the

people who are asking for it with '-w'.

Post by David Nadlinger via Digitalmars-d
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141005/1ea0e4bd/attachment.html>

[Martin Nowak via Digitalmars-d]

Post by David Nadlinger via Digitalmars-d
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.

[David Nadlinger via Digitalmars-d]

On Friday, 26 September 2014 at 21:13:14 UTC, Daniel Kozák via

Post by Daniel Kozák via Digitalmars-d
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

[Kenji Hara via Digitalmars-d]

2014-09-27 1:15 GMT+09:00 David Nadlinger via Digitalmars-d <

As Walter mentioned in a recent pull request discussion [1], the first
formal deprecation protocol we came up with for language changes looked
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140930/60e91f3a/attachment-0001.html>