A possible solution for the opIndexXxxAssign morass

[Robert Jacques]

On Tue, 13 Oct 2009 11:56:36 -0400, Don <nospam at nospam.com> wrote:

> Andrei Alexandrescu wrote:
>> Right now we're in trouble with operators: opIndex and opIndexAssign  
>> don't seem to be up to snuff because they don't catch operations like
>>  a[b] += c;
>>  with reasonable expressiveness and efficiency.
>>  Last night this idea occurred to me: we could simply use overloading  
>> with the existing operator names. Consider:
>>  a += b
>>  gets rewritten as
>>  a.opAddAssign(b)
>>  Then how about this - rewrite this:
>>  a[b] += c
>>  as
>>  a.opAddAssign(b, c);
>>  There's no chance of ambiguity because the parameter counts are  
>> different. Moreover, this scales to multiple indexes:
>>  a[b1, b2, ..., bn] = c
>>  gets rewritten as
>>  a.opAddAssign(b1, b2, ..., bn, c)
>>  What do you think? I may be missing some important cases or threats.
>>   Andrei
>
> Well timed. I just wrote this operator overloading proposal, part 1.
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
> I concentrated on getting the use cases established.
>
> The indexing thing was something I didn't have a solution for.
>
> BTW we need to deal with slices as well as indexes. I think the way to  
> do this is to make a slice into a type of index.
>

I've mentioned this problem before, in relation to multi-dimensional  
arrays:

// Slice a row out of an Matrix
row0 = myMatrix[0,0..$];

So basically, opIndex and opSlice need to merge to support this use case.  
I've always ended up doing this with using size_t[2] or size_t[3] (for  
slicing with strides) when I've coded Nd-arrays, though this is a bit  
clunky. However, a while ago someone mentioned that tuple, though  
cool/useful/etc wasn't being used as much (compared to other languages)  
because of a lack of syntactic sugar. Which gave me the idea of using the  
.. operator to be syntactic sugar for tuple, as it would solve two birds  
with one stone. (Maybe three, if you count MVR)

Also needed is an extension of the opDollar to return different values  
based on the index:
opDollar(size_t index);

P.S. There's also at least one template bug blocking Nd-arrays and small  
vector types: (http://d.puremagic.com/issues/show_bug.cgi?id=2257).
P.S.S. Another template issue is that templating both opX and opX_r  
generally results in an overload conflict.