A possible solution for the opIndexXxxAssign morass

[Denis Koroskin]

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.