A possible solution for the opIndexXxxAssign morass

[Steven Schveighoffer]

On Tue, 13 Oct 2009 11: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)

I'm guessing you meant opAssign here, or 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.

-Steve