On 12/1/2012 4:47 AM, bearophile wrote:
> In another thread people are discussion a solution that will help you, a
> "Stable D", updated only once in a time, like every 6-8-12 months, that
> has no know regressions and where only nonbreaking changes are allowed
> (here Phobos modules deprecations are probably to be intended as
> breaking changes).

I don't view the stable/dev branches of D as being a license to break existing code. Breaking code in the dev version should only be done if there's a very large benefit/cost ratio.

Not for bikeshedding reasons, and not if there's a way we can keep the old behavior around.

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.

- Jonathan M Davis

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.

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

On Sunday, 2 December 2012 at 23:56:29 UTC, Jonathan M Davis wrote:
[... <breath> snip </breath> ...]

> 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

+1

To resolve this kind of no-win argument, you have to solve the root problem.

You cannot use an unstable version of D as a stable version, for obvious reasons, each new stable release of D "stable" appears to be a new unstable release of D.

It won't work to simply lock down D into only a stable version. Doing that will piss off a lot of people who want to see new breaking improvements implemented and released for use, and not 5 years later either, but a lot sooner.

Here's a simple example of a possible real solution for Phobos, for sake of discussion I'm assuming DMD will be released under a major.minor.revision numbering system, with stable and unstable branches.

1) Assign Phobos it's own independent major.minor.revision number with the major number locked in with the corresponding compatible major DMD number. That way, users will know what Phobos version is compatible with what DMD version.

2) Include multiple backwards compatible versions of Phobos with each DMD release stored in a way that allows versions of Phobos to be selectable by the D programmer.

I know that there are plenty of challenges to overcome wrt changing the way D is being developed and released, but to try and develop D using only one version for both stable and unstable is simply not going to work. It also will not work to lock down D and prevent it from improving in breaking ways overthe next 5 years (or whatever).

--rt

On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
>> 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
> +1


-1. There's really no harm in leaving it there. On my hard drive, I have somewhere in the ballpark of a gigabyte of code saved (includes random apps I've compiled over the years).

I don't know what most of it is, and I don't really care. If I need it, its there, and if not, whatever, there's not much, if anything, of a downside to having crap saved. My hard drive is still 75% free, access to the files I want is as fast as ever, and so on.

With deprecated alias.... if you don't use it, whatever. With old code, if you don't use it.... you won't even notice its there.

The only real downside I can think of is making the full download a bit slower. I don't think this is important. zipped code is small code. Besides, with the real world "problem" today, what are we even talking about? 50 kilobytes? Big deal.

On Monday, December 03, 2012 02:49:39 Rob T wrote:
> I know that there are plenty of challenges to overcome wrt changing the way D is being developed and released, but to try and develop D using only one version for both stable and unstable is simply not going to work. It also will not work to lock down D and prevent it from improving in breaking ways overthe next 5 years (or whatever).

There is still a considerable difference between a library which is intended to be stable and one which is under heavy development. We've essentially been working under a model where the API was fluid enough that we could break code as long as we gave enough warning first. We want to move to a model where the API is stable enough that code written now will compile 5+ years from now with no changes. We can still look at phasing out stuff that needs to be replaced. It's just that we then need to keep it around (even if it's deprecated and undocumented), whereas when the API is under heavier development, more permanent breakage has been permissible. For instance, std.date is dead and gone, having been replaced by std.datetime, and that was a good decision at the time given the level of stability of the library. But if we were to replace std.xml with std.xml2 now, we would need to keep std.xml around long term (even if it's deprecated and undocumented) so that code would continue to compile for years to come, because we've reached a point when we want to have a stable API that people can rely on rather than trying to clean up all of the little things that we were trying to clean up before.

So, yes having a development and stable branch will help manage things, but even with that separation, we don't want to be breaking people's code due to library changes.

- Jonathan M Davis

On Monday, December 03, 2012 02:58:57 Adam D. Ruppe wrote:
> On Monday, 3 December 2012 at 00:52:55 UTC, Joshua Niehus wrote:
> >> 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
> > 
> > +1
> 
> -1. There's really no harm in leaving it there. On my hard drive, I have somewhere in the ballpark of a gigabyte of code saved (includes random apps I've compiled over the years).
> 
> I don't know what most of it is, and I don't really care. If I need it, its there, and if not, whatever, there's not much, if anything, of a downside to having crap saved. My hard drive is still 75% free, access to the files I want is as fast as ever, and so on.
> 
> With deprecated alias.... if you don't use it, whatever. With old code, if you don't use it.... you won't even notice its there.
> 
> The only real downside I can think of is making the full download a bit slower. I don't think this is important. zipped code is small code. Besides, with the real world "problem" today, what are we even talking about? 50 kilobytes? Big deal.

It's messy and ugly to leave dead code around in a library. It also makes it so that it's possible for people to keep writing code which uses it when they shouldn't be.

I'm all for moving to a model where we keep deprecated stuff around for stuff that we deprecate in the future, but I'm completely against leaving the stuff that we currently have deprecated around. It was changed in an effort to clean up the library in preparation for having a clean, stable API, and leaving it around is messy and counter to that purpose.

- Jonathan M Davis

On 12/3/2012 1:03 PM, Jonathan M Davis wrote:
> It's messy and ugly to leave dead code around in a library. It also makes it
> so that it's possible for people to keep writing code which uses it when they
> shouldn't be.

It is not dead code, there are people using it.

As for aesthetics, it can be moved to the end of the module, and visually segregated.

Also, if the documentation for it is removed, I seriously doubt that sensible people will use it in new code.


> I'm all for moving to a model where we keep deprecated stuff around for stuff
> that we deprecate in the future, but I'm completely against leaving the stuff
> that we currently have deprecated around. It was changed in an effort to clean
> up the library in preparation for having a clean, stable API, and leaving it
> around is messy and counter to that purpose.

Breaking peoples' existing, working, stable code is worse than offending a notion of clutter, especially because only phobos developers will even see that clutter.