A possible solution for the opIndexXxxAssign morass

[Denis Koroskin]

On Tue, 13 Oct 2009 20:34:06 +0400, Robert Jacques <sandford at jhu.edu>  
wrote:

> On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2korden at gmail.com>  
> wrote:
>
>> On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> 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
>>
>> How about this case:
>>
>> a[b1..b2] = c;
>>
>> ?
>>
>> I could be solved if b1..b2 would return some built-in range type,  
>> defined in object.d, though.
>
> That already has an operator:
> int opSliceAssign(int v, size_t x, size_t y);
> a[3..4] = v;	// same as a.opSliceAssign(v,3,4);

I meant:

a[b1..b2] += c;

Another thing I dislike about this proposal is that "a[b] += c;"  
translates into "opAddAssign" and doesn't mention "index" while "a[b] =  
c;" does ("opIndexAssign").