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