Operator overloading -- lets collect some use cases

[Andrei Alexandrescu]

Don wrote:
> Don wrote:
>> There's been some interesting discussion about operator overloading 
>> over the past six months, but to take the next step, I think we need 
>> to ground it in reality. What are the use cases?
>>
>> I think that D's existing opCmp() takes care of the plethora of 
>> trivial cases where <, >= etc are overloaded. It's the cases where the 
>> arithmetic and logical operations are overloaded that are particularly 
>> interesting to me.
>>
>> The following mathematical cases immediately spring to mind:
>> * complex numbers
>> * quaternions
>> * vectors
>> * matrices
>> * tensors
>> * bigint operations (including bigint, bigfloat,...)
>> I think that all of those are easily defensible.
>>
>> But I know of very few reasonable non-mathematical uses.
>> In C++, I've seen them used for iostreams, regexps, and some stuff 
>> that is quite frankly bizarre.
>>
>> So, please post any use cases which you consider convincing.
> 
> Some observations based on the use cases to date:
> (1)
> a += b is ALWAYS a = a + b (and likewise for all other operations).
> opXXXAssign therefore seems to be a (limited) performance optimisation. 
> The compiler should be allowed to synthesize += from +. This would 
> almost halve the minimum number of repetitive functions required.

I don't think compiler technology is good enough to automatically 
synthesize += from + for e.g. matrices. An easier path would be to 
synthesize + from +=, but sometimes that would be suboptimal.

> A straightforward first step would be to state in the spec that "the 
> compiler is entitled to assume that X+=Y yields the same result as X=X+Y"

I think that's a good idea.

> (2)
> There seems to be a need for abstract syntax trees, which is NOT 
> necessarily related to performance. (If we had a 'perfect performance' 
> solution for operator overloading, it would not remove the desire for 
> abstract syntax trees).
> (3)
> The array operations ~, [], [..] need further attention. A solution for 
> $ is also required.
> 

Cool.


Andrei