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

[Nick B]

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.

On July 09, Bartosz mentioned the following:

"The bottom line of this post is that the current Thread object in D 
should be abandoned and replaced by a more primitive "spawn" function. 
If there are no serious objections, we are going to proceed with the 
rewrite."

If think that its arguable that "the replacement of the current Thread 
object" is seperate from  Multithreading (I & II) above. I think this 
should be clarified if this is part of D2.0