Developing a plan for D2.0: Getting everything on the table

[Don]

Don wrote:
> A lot of frustration has been expressed on the newgroup about lack of a 
> clear public plan for D2.0. I don't think we're in a position to create 
> a road-map. But, let's at least agree on which countries we'll probably 
> visit before we reach our final destination <g>.
> 
> Everyone knows there are a multitude of significant bugs in Bugzilla, 
> and most people have their pet list of minor language warts they hope 
> will be removed. But there's also some earthquake issues that have huge 
> implications. It's very disconcerting when some of them are introduced 
> in a casual manner. I think it would reduce a lot of frustation in the 
> community if we compiled an official list of the major ones. Here's a 
> few I came up with:
> 
> - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
> - Multithreading (II): Will some form of message parsing be included?
> - Operator overloading. "completely redone" (?)
> - opImplicitCast
> - is T[new] still going to happen?
> - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
> - Unimplemented features -- safe D, contract inheritance.
> - Andrei once said that he wants to get rid of new (!)
> - The Tango license issue needs to be sorted to the extent that Andrei 
> and Walter feel they can safely look at the Tango code; OR we can decide 
> that's not going to happen, and change the strategy for the Tango/Phobos 
> relationship.
> 
> The stuff on this list will either be implemented, or dropped. New 
> things could be added to the list. But we can gauge our progress towards 
> D2.0 by how rapidly the list shrinks with time.
> 
> Which other major issues have I missed? Things which, if they happen, 
> will probably require major spec changes, major library redesign, or 
> break large amounts of code. Let's get everything on the table.

I've put this list on the D wiki at:
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2

If it becomes complete enough, maybe it can go into the 'future' page in 
the next compiler release.
(The future page says that 'array operations are planned but the details 
have not been worked out'. So it shouldn't be hard to improve on <g>).