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