deprecate deprecated?

Jonathan M Davis jmdavisProg at gmx.com
Fri Nov 9 01:05:47 PST 2012


On Friday, November 09, 2012 00:49:19 Walter Bright wrote:
> On 11/8/2012 12:13 AM, Don Clugston wrote:
> > That *cannot* fix the problem.
> > The problem is not with the deprecated attribute at all, it's with the
> > command line switches.
> 
> Of interest:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
> 
> Looks like another D feature moving into C++!

One major difference in what they're describing vs what we have is that for us, 
deprecated immediately triggers an error, whereas for them, it's a warning by 
default. I think that we'd to well to change to that scheme to match theirs 
(though have whether it's treated as an error be kept separate from -w so that 
normal warnings because many people compile with it normally). That way, by 
default, deprecating something doesn't break people's code but rather simply 
encourages them to change it, and their code won't be broken until the symbol 
is actually remove from the library or they choose to compile with -dw (or 
whatever we name the switch that makes using deprecated symbols an error).

As it stands, if we don't want to break anyone's code, we can't really use 
deprecated, whereas if it were changed to warn by default, we _could_ use it 
where appropriate and thereby encourage people to change their code but not 
break anyone's code. It also avoids the problem of people not being aware that 
something is going to be deprecated before their code stops compiling due to 
it being deprecated or removed, since right now, the only way to know if 
something is going to be deprecated is to read the changelog or documentation, 
which many people won't read.

- Jonathan M Davis


More information about the Digitalmars-d mailing list