A possible solution for the opIndexXxxAssign morass

[Robert Jacques]

On Tue, 13 Oct 2009 12:21:20 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> 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)
>>  I'm guessing you meant opAssign here, or meant to write +=?
>
> Oh, sorry. I meant to write +=.
>
>>> What do you think? I may be missing some important cases or threats.
>>  It's simple, and gets rid of all opIndex operators except for opIndex  
>> itself.
>>  The question then becomes, what if you wanted to overload this?
>>  a[b][c] += d;
>>  You can do a[b] returns a ref.  But then you now allow a[b] op x,  
>> thereby possibly exposing a private piece of info.  This may or may not  
>> be important.
>>  I like the way your idea is going.
>
> Great. Indeed the proposed solution leaves a[b][c] += d problematic, and  
> also prevents this potential development:
>
> a += b + c + d;
>
> to be rewritten as:
>
> a.opAddAssign(b, c, d);
>
>
> Andrei

Well, that last case I'd prefer handled by something more generic, like an  
opExpression(Expr, T...)(T params); (i.e. a way of doing expression  
template/ BLADE like stuff, without the syntactic or runtime overhead.