A possible solution for the opIndexXxxAssign morass

[Don]

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.