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
