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

[Andrei Alexandrescu]

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>.

This is a great initiative. Let me add a few small points.

> 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)?

I don't know. This is mostly up to Walter.

> - Multithreading (II): Will some form of message parsing be included?

(Passing I guess?) Yes, that's a definite yes.

> - Operator overloading. "completely redone" (?)

I think they should be redone. There are several issues:

1. Currently there's no provision for "expr1[expr2] @= expr3", where @ 
is some binary operator. The opIndexAssign is more like the token 
presence that makes the absence felt even better. Scaling to 
opIndexAddAssign etc. seems to be overkill.

2. Operators @= are dubious for classes because a class can't define "a 
@= b" to mean the same as "a = a @ b". (I recall you were the first to 
note that.) I'd venture to think that many arithmetic operators don't 
make much sense for classes to start with.

3. There are types for which ++ or -- make sense but addition does not 
(e.g. STL-style iterators).

4. opXxx_r and opXxx can easily be ambiguous, as you noted in a recent 
thread. (I think that could be fixed with other means though.)

5. Defining operators asks for code duplication. Usually people want to 
define all arithmetic operators to forward to some member. That is 
unnecessarily verbose (see e.g. the implementation of std.variant which 
makes heroic efforts to counter that).

Any other issues? (I feel I forgot a couple.) Maybe we can fix all of 
these by patching the existing system.

> - opImplicitCast

I think alias this should render that unnecesary.

> - is T[new] still going to happen?

I don't know.

> - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.

The intent is to make all of I/O range-based such that e.g. files and 
other streams can be combined through std.range and std.algorithm in 
various ways.

> - Unimplemented features -- safe D, contract inheritance.
> - Andrei once said that he wants to get rid of new (!)

Why "!"? :o)

> - 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.

There are many unfinished things, such as construction of immutable and 
const objects; a solid approach to unicity, moving, duplication, and 
marshaling; unification of overloading across templates and 
non-templates; I'll relay more as I remember.


Andrei