dmd 1.069 and 2.054 release

[Jonathan M Davis]

On Tuesday 12 July 2011 23:38:10 Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > The current plan is that _everything_ which gets deprecated will
> > be removed.
> 
> What's the reason for removing things? Surely it's not disk space!
> 
> 
> Anyway, let's look at the three categories. While I hate change,
> there are two kinds of change: trivial and painful. Remember, D
> isn't a useless piece of junk dynamic language - trivial changes
> are easy to find and easy to change with confidence.
> 
> Painful changes though, are, well, painful.
> 
> > 1. Renaming stuff to follow Phobos' naming conventions.
> 
> These are trivial, just change it. It's like ripping off a band-aid.
> The compiler will tell you what broke and how to fix it (the spell
> checker ought to catch camelcase changes without keeping the old
> name).
> 
> Do it fast, feel the brief pain, and move on.

Hmm. I don't think that Walter would be very happy about that, since it does 
immediately break code, but as long as the name change is easily found by the 
spellchecker, it wouldn't be a big deal to fix. So, under at least some 
circumstances, that may be acceptable. Regardless, it could be grounds for 
making the deprecation cycle for renaming relatively short instead of around 1 
year as is the current plan for deprecation in general.

> > 2. Small redesigns of older functionality.
> 
> These should be reasonably trivial fixes too, but might warrant
> deprecating the old on a case by case basis. If it's mindless
> to change though, just rip that bandage off.
> 
> Just make sure that the types are different or something, while
> still super easy to change, so the compiler will point it out to you.
> 
> > 3. Full module redesigns due to the need of serious improvement
> 
> This is where the pain comes in, since instead of spending 15
> minutes running a mindless find/replace when the compiler tells
> you to, it requires gutting a lot of code and rethinking it,
> converting databases, etc.
> 
> These should ideally aim to redesign the internals, but keep the
> same interface. Maybe adding to it or writing the old as an
> emulation layer over the new.
> 
> This is preferred, since then new and old exist together. It avoids
> actually breaking anybody's code.
> 
> 
> If that's impossible though, this is the most likely candidate
> for deprecation. Unlike a name change, it isn't easy to change,
> so a compile error is more likely to mean reverting dmd versions
> than actually changing it.

At this point, I expect that the module rewrites are going to generally be 
full-on, completely incompatible rewrites. Fixing the API is one of the major 
reasons for the rewrites (particularly when converting a module  to being 
range-based as is going to occur with std.stream), so just changing the 
implementation isn't going to cut it. It may be that in some cases, it's 
essentially a rewrite of a broken implementation, but I'm not aware of any 
such case at the moment. These are definitely cases, however, where the full 
deprecation cycle is going to be used, so there should be plenty of time to fix 
code. Hopefully, these changes get done fairly soon, but some of them don't 
seem to be going anywhere yet in spite of major discussions about them (e.g. 
std.stream). They're also the most work to do, so while I would expect most of 
the #1 and #2 types of deprecations to occur fairly soon for the most part, 
the full module rewrites could take a while, which is unfortunate.

Off the top of my head, I know that std.xml, std.stream, std.path, and std.json 
are going to get rewrites on some level, and std.container could get some 
major rewrites depending on what Andrei does with memory management in it, 
though what it needs primarily is new containers. Also, Andrei thinks that 
std.encoding is a failed experiment which needs to be redone, so that's 
probably going to need to be rewritten at some point. And as I understand it, 
all of those except for std.stream and std.encoding have someone actively 
working on them (though maybe Andrei has been working on std.stream too; I 
don't know). So, hopefully it won't be too much longer before they're done, 
but it could also be a while unfortunately.

So, anyway, there are some module rewrites to be done, and they're likely to 
be pretty major for better or worse. But once those are done, with the review 
process vetting new modules, deprecation issues like these should be far 
rarer, and Phobos should be heading towards stability.

- Jonathan M Davis