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.

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

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.

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

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

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

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.

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?

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