Deprecated Library Functions / Methods

[Jonathan M Davis]

On Monday, December 03, 2012 08:28:30 Walter Bright wrote:
> On 12/2/2012 11:52 AM, Jonathan M Davis wrote:
> > We _were_ looking at outright throwing std.xml away at one point and then
> > replacing it later, given how bad it is, but we never quite did that, and
> > at this point, I wouldn't expect it to happen. We've been focusing more
> > on avoiding breaking code of late, and so, doing something like that
> > probably wouldn't be deemed acceptable at this point.
> 
> For this case (and others like it) I strongly suggest putting the revamp
> in something called std.xml2, and keep std.xml, but let std.xml wither
> and die away of its own accord rather than killing it.
> 
> For example, after a while it can be removed from the web site
> documentation.

That's basically what I'd expect to happen with this.

And if you accept dmd pull# 1287, then that's probably how deprecation will be 
handled in general in the long term. Without that, I'm not sure what we're 
going to do, since then deprecating _anything_ breaks code.

Regardless, there's some stuff that's already been deprecated which probably 
should be outright removed at some point here (e.g. the deprecated functions 
in std.string which don't follow the correct naming conventions), but once 
that sort of thing has been removed, I think that we should be moving to a 
model where deprecated stuff becomes undocumented and withers away only to be 
outright removed with a major release of some kind. Such removals could be 
made to fit into the stable branch model somehow, but the deprecated symbols 
would be around a long time before being removed with a major release, and 
depending, we may not even remove them then. But as deprecations should be 
becoming rarer as the library stabilizes, this should be less of an issue.

- Jonathan M Davis