Operator overloading

[Andrei Alexandrescu]

aarti_pl wrote:
> Don pisze:
>> As I see it, there are two possible strategies:
>> (1) Pursuing optimal performance, which requires semantic tightening, 
>> and reduced flexibility, or
>> (2) Pursure simplicity and semantic flexibility, sacrificing performance.
>>
>> I think those two possibilities are mutually exclusive.
> 
> Well, I think you have just discovered two levels of programmers 
> interests in operator overloading :-)
> 
> * First level (group) is for programmers which want to use operators to 
> create fast mathematical operations for user defined types.
> 
> * Second level (group) is for programmers which want to use operators 
> for creating better syntax, to make their users more happy.
> 
> It seems that both groups have good reasons for their requests.
> 
> As you said these two possibilities are mutually exclusive, so I think 
> also solution for this challenge should be splitted, so that everyone 
> could get what he want.
> 
> One possible solution is to allow defining operator overloading on two 
> levels also:
> 
> 1. In first level, where operators are used for computation, there might 
> be operators like today in D: opCmp, opEquals. They can be even stricter 
> and/or better defined as needed.
> 
> 2. Second level should be just raw operator access, which allows to use 
> operator syntax in wider scope of cases.
> 
> Compiler should enforce the rule that operators from two levels can not 
> be intermixed in one class/struct.
> 
> I think that such a solution could make these two groups have their 
> goals achieved.
> 
> BR
> Marcin Kuszczak
> (aarti_pl)

That can be achieved by only defining the low-level operators in the 
language and then developing a library layer on top of them.

Andrei