Argumnentation against external function operator overloading is unconvincing

[Timon Gehr via Digitalmars-d]

On 23.09.2016 12:44, Stefan Koch wrote:
> On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote:
>>
>> FQN disables UFCS. Nothing specific to operators here.
>>
>> There is no reason why there should be any difference between a + b
>> and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should work too.
>
> Currently this is tricky to implement in the compiler.

This can easily be implemented in the parser and in object.d without 
even changing semantic. This is not the best implementation strategy, 
but it demonstrates that implementation can be simple. I'm curious to 
know what strategy you have in mind, and why it would be tricky.

BTW: One case for why built-in types should have member call syntax for 
operators are all the places in e.g. Phobos where code special-cases 
built-in types in order to be able to use opCmp directly for three-way 
comparison on user-defined types.

> And it widens the scope for name-conflicts immensely!
> ...

Operator overloading makes sense for a small minority of types and D has 
plenty of mechanisms to deal with name conflicts: overload sets, 
template constraints, private aliases, FQNs.

> I do not see a case where UFCS overloaded operators are worth the
> trouble they introduce.

IMHO it's a trivial surface language feature allowing convenient syntax 
for a restricted set of user types. The current limitations are slightly 
confusing (because a.opBinary!"+"(b) is somehow not the same as 
a.opBinary!"+"(b)), and also annoying when you run into them. This is 
not the first time this is discussed.