A possible solution for the opIndexXxxAssign morass

[Lars T. Kyllingstad]

Don wrote:
> 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.


I like the idea of enforcing relationships between operators. In fact, I 
think we can take it even further, and require that operator overloading 
in general *must* follow mathematical rules, and anything else leads to 
undefined behaviour. For example, if n is an integer, a and b are 
scalars, and x and y are general types, the compiler should be free to 
rewrite

          n*x  <-->  x + x + ... + x    <-->  2*x + 2*x + ...
         x^^n  <-->  x * x * ... * x    <-->  x^^2 * x^^2 * ...
    x/a + y/b  <-->  (b*x + a*y)/(a*b)

and so on, based on what it finds to be the most efficient operations. 
(Note how I snuck my favourite suggestion for an exponentiation operator 
in there. I *really* want that.)

-Lars