Deprecated Library Functions / Methods

[Jonathan M Davis]

On Monday, December 03, 2012 10:32:55 Walter Bright wrote:
> On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
> > On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
> >> On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
> >>> 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),
> >> 
> >> I do not see a compelling reason to remove them. Just leave them
> >> deprecated.> 
> > They're clutter, and they've been deprecated for a while, which means that
> > no one has been able to use them without -d for a while. It's also
> > trivial to fix code which uses them, because they're primarily naming
> > changes. It's just not worth keeping that kind of clutter around in the
> > library IMHO. And the documentation has made it clear that they were
> > going to be removed.
> This is really the crux of our disagreement. I do not see a problem with
> leaving "clutter" around if it prevents breaking existing code. It being
> trivial to fix user code is not good enough - the fact that the user has
> to go back and fix stable, working, debugged code is the problem that
> Chris is saying is preventing him from using D seriously.
> 
> Remove them from the documentation, ok, but leave them there. It does
> not hurt to do so. Let them die on their own, we do not need to push
> them out the airlock.

Then we're definitely going to disagree. Ideally, no deprecated code would 
stick around long term. But that creates a practical problem as we do need 
code to be able to continue to compile for a very long time even if it's not 
updated, so we do often need to keep deprecated code around long term. In this 
case, however, we're talking about changes which have long since broken code 
and which were part of a major shift when cleaning up the library. The only 
code which would be using them at this point is code that hasn't been updated 
in quite some time, and so much has changed in both the compiler and the 
library since those changes were made, that it's not likely that code that old 
would still work anyway.

With an appropriately stable language and API, deprecations can and should 
take a very long time and possible stick around permanently. But neither the 
language nor the standard library has been treated as being that stable. 
They've been becoming more stable, but they've been a work in progress and as 
such have been breaking code. As we shift to to them being stable, 
deprecations will then be rarer and more reasonable to keep around. It'll also 
be far more reasonable to expect code older than a release or three to 
continue to compile with new releases, which has definitely not been the case 
with a lot of the library changes that were made in the past (most of which 
have been completed - the std.string stuff is some of the last stuff still 
around). I honestly don't expect code compiled with 2.051 to continue to work 
in general. Too much has changed since then, much of which was done in an 
attempt to clean up Phobos prior to committing to having a stable API that we 
expect to continue to work for years to come. We've been giving people who 
maintain their code ample notice and ample time to fix their code as we've 
progressed, but we haven't been operating with the idea that old code would 
compile 9 releases later. Rather, we've been trying to clean stuff up so that 
we could operate that way without having to maintain bad code forever (or to 
at least minimize that). We do need to start operating with the idea that code 
will compile 9+ releases later, but stuff like the std.string deprecations were 
not done with the idea that they would stay around long term.

So, I see stuff like the std.string deprecations as being fundamentally 
different from deprecations that will happen in the future. We're moving from a 
model where we were trying to clean up the standard library in order to 
stabilize it to one where it's stable and shouldn't be changing that much 
aside from additions. And I think that it's perfectly reasonable to treat 
deprecations differently in those two situations. So, I'm definitely going to 
push for removing stuff that's already been deprecated. It's already broken 
people's code by being deprecated due to how deprecated currently works, so 
it's really not going to cost anyone much for them to be outright removed now. 
And in the case of the std.string deprecations, they'll even get nice messages 
asking them things like if they really meant toLower instead of tolower.

I don't like leaving clutter in code, and in this case, I think that it's safe 
and reasonable to clean up that clutter.

- Jonathan M Davis