opDispatch and operator overloads

Timon Gehr timon.gehr at gmx.ch
Mon May 20 12:48:48 PDT 2013


On 05/20/2013 09:26 PM, Maxim Fomin wrote:
> On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
>> struct S {
>>     auto opDispatch(string s)(A i){}
>> }
>>
>> struct A {}
>>
>> void main() {
>>     S s;
>>     A a;
>>     s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
>> }
>>
>> It would be really nice if opDispatch could catch missing operator
>> overloads.
>
> This would also leads to bugs when invalid code is silently accepted in
> each user-defined type where opDispatch is defined.
>

This statement is wrong. As a counterexample, consider the following code:

struct S{
     void opDispatch(string s)()if(s=="foo"){ }
}

Also, I'd claim that there is no way of constructing an example where 
the change leads to actual problems. (It is always possible to manually 
remove the syntax sugar to get an equivalent program without operator 
overloading.)

The current situation where there exist types for which 
a.opBinary!"+"(b) is valid but not a+b is confusing at best.

>> Also, would it be a good idea to have free functions of all the
>> operators (opOpAssign etc...) for builtin types somewhere? It's
>> occasionally useful in generic wrappers.
>
> And this is pushing UFCS beyond its purpose for the sake of temporal
> convenience at the expense of language.

He was assuming, based on the language spec I suppose, that UFCS is 
compatible with operator overloading. His use case is orthogonal to that 
issue.


More information about the Digitalmars-d mailing list