Behavior of opEquals

[Jonathan M Davis via Digitalmars-d]

On Monday, 7 September 2015 at 10:26:00 UTC, Timon Gehr wrote:
> On 09/05/2015 08:18 AM, Jonathan M Davis wrote:
>> On Friday, 4 September 2015 at 20:39:14 UTC, Timon Gehr wrote:
>>> On 09/04/2015 09:21 PM, H. S. Teoh via Digitalmars-d wrote:
>>>>
>>>> Wait, wait, did I miss something? Since when was operator 
>>>> overloading
>>>> allowed as free functions?
>>>
>>> Since UFCS, but DMD does not implement it.
>>
>> There is nothing in the spec about supporting operator 
>> overloading with
>> free functions, so I don't know where you get the idea that 
>> it's even
>> intended to be a feature. UFCS applies to functions which use 
>> the member
>> function call syntax, and operators aren't used that way.
>
> Specifying semantics via lowering is somewhat pointless if 
> rewrites are not transitive.

Specifying semantics via lowering makes the compiler simpler and 
the expected behavior easier to understand. Nothing about that 
requires that it transitively apply all syntactic sugar, and UFCS 
is simply syntactic sugar. Sure, it _could_ be implemented that 
way, but the only reason I see to do that is if we're 
specifically looking to support defining overloaded operators 
outside of the types that they apply to. I can't think of 
anything else that would be affected by it.

Regardless, I honestly think that it would be a very bad 
technical decision to support defining overloaded operators 
outside of the type itself - _especially_ when you take into 
account operators that have defaults generated by the compiler 
(e.g. opEquals), since that would allow a third party to change 
what your code does by adding their own overloaded operator. And 
IIRC, Walter has explicitly stated that it's purposeful that you 
cannot define overloaded operators outside of the struct/class 
that they're for. So, anyone who wants it to be otherwise is 
going to have to convince him.

- Jonathan M Davis