A possible solution for the opIndexXxxAssign morass

[Bill Baxter]

On Tue, Oct 13, 2009 at 9:08 AM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> 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.

Huh? It didn't sound to me like it would get rid of anything, except
for the use of the word "index" in many methods that have to do with
index operations.  That just seems confusing to me.   I think the
opIndexXxxAssign functions may need to be added, but adding them by
overloading existing names doesn't seem a win to me.

--bb