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)
