A possible solution for the opIndexXxxAssign morass

[Robert Jacques]

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