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
