Operator overloading

[aarti_pl]

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)