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

[Robert Jacques]

On Tue, 14 Jul 2009 12:42:56 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:
> Don wrote:
>> - 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.

I slicing and indexing need to be unified, as its common with  
multi-dimensional data to slice one dimension and index another. Consider  
slicing the first row of a matrix:
auto row0 = m[0,0..$];
(Also a multi-dimensional opDollar ->i.e. opDollar(size_t D){}, is needed)