opDispatch and operator overloads

[Maxim Fomin]

On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
> On 05/20/2013 09:26 PM, Maxim Fomin wrote:
>> 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.
>

I refer to more complex cases where fear introduction of subtle 
bugs caused by combination of buggy implementation and unintended 
consequences which would be revealed as unexpected behavior 
change of existing features. In some notorious cases such 
artificiality created problems (for local convenience at the 
expense of language consistency) are not easy to fix (ref), or 
are unfixable by design (@disable), or are broken and dumped 
without touch for ages (delegates).

Clearly, bugs should not stop from implementing a good feature, 
but here I see low benefits and some problems.

>>> 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.

Yes, it is separate story.