SeeWebsiteForEmail at erdani.org
Sat Dec 27 15:32:44 PST 2008
> 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.
> Marcin Kuszczak
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