dmd 1.069 and 2.054 release

[Jonathan M Davis]

On 2011-07-12 15:09, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > Deprecating something is still going to break code
> 
> Breaking with deprecated is an entirely different kind of breakage
> than removing something.
> 
> deprecated means simply "please don't use this specific thing". You
> can tell it "shut up I know better than you" and be on your way.
>
> It's in your face enough that you can change it right there and then
> if you want to, but it's easy enough to shut it up too. 

True. But Walter has been pretty insistent that things not be deprecated 
without warning first, because code which compiled perfectly before doesn't 
anymore, even if all you have to do is change your build scripts.

Now, as for the "scheduled for deprecation" messages, we can stop doing that. 
But then the documentation is going to be the only thing warning anyone, and 
then code is going to get broken when stuff is actually deprecated. Given the 
fact that you can use -d, that's not the end of the world. But it does mean 
that deprecation is going to tend to come out of nowhere for most people, and 
Walter has been very adamant about avoiding suddenly breaking people's code - 
even by requiring them to add -d to their build scripts.

So, if most people don't want the messages, then the messages will go away. 
But that means that people actually need to pay attention to the changelog and 
documentation.

> Here's my preference list for changes:
> 
> Top preference: don't change stuff.
> 
> Next: use the deprecated attribute
> 
> Next: versioned scheduled to be deprecated messages. I don't like
> being spammed every time I compile.
> 
> Next: scheduled to be deprecated messages as they are now
> 
> Last: removing it entirely. (this should be very, very rare
> especially if we want to be called stable. Nothing has pissed me
> off more with the last few releases than Phobos losing
> functionality.)

The current plan is that _everything_ which gets deprecated will be removed. 
Stuff which is deprecated is not intended to stick around. Now, it should be 
pretty rare that deprecated stuff doesn't have a replacement. Outright 
removing functionality should be very rare indeed. It may happen in a few 
cases where the functionality just isn't generally useful, but overall, it 
should be rare.

Deprecation is likely to fall primarily in 3 categories at this point:

1. Renaming stuff to follow Phobos' naming conventions. A lot of this was 
fixed with 2.054, but there's still some left to do. For the most part though, 
this should be a set of fixes which will be done fairly soon and then we won't 
have to make those kind of changes again.

2. Small redesigns of older functionality. The prime case that I can think of 
is that there has been talk of replacing the use of patterns in std.string 
with uses of std.regex.Regex.

3. Full module redesigns due to the need of serious improvement. std.datetime 
replacing std.date would be a prime example of this, but there are a few other 
modules which are supposed to be redesigned (e.g. std.xml and std.stream).

The idea at least is that these sort of changes should be taking place fairly 
soon and that we then won't need to do any of that kind of thing anymore (or 
at least only very rarely). The review process should catch most of these sort 
of issues before they actually get into Phobos in the first place. But some 
code has not aged well as D and Phobos have changed, and Phobos has not always 
been consistent in naming, and that needs to be fixed sooner rather than 
later.

- Jonathan M Davis