Operator overloading

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Dec 27 15:32:44 PST 2008

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.


More information about the Digitalmars-d mailing list