Behavior of opEquals

[Timon Gehr via Digitalmars-d]

On 09/08/2015 06:49 PM, Jonathan M Davis wrote:
> 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

Not necessarily. The compiler can do lowering (even using internal 
syntax tree nodes that have no D syntax equivalent!) no matter how the 
behaviour is specified. It's just easier to come up with the required 
compiler code and to verify it if the specification does it this way.

> and the
> expected behavior easier to understand. Nothing about that  requires that
> it transitively apply all syntactic sugar, and UFCS is simply syntactic
> sugar.


All about that requires that it applies all rewrites transitively. It is 
the entire point that the lowered version is again plain D code. (Also, 
UFCS is not "simply syntactic sugar". There are special lookup rules. 
Operator overloading ought to be the simple syntactic sugar here, but it 
isn't, because built-in types don't define the respective operator 
overloading functions. They should.)

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

The compiler does not match the specification. I see no reason to change 
the specification here, but it would be easy.

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

Well, how? "Overloaded operators" are just specially named functions 
that support an additional call syntax. There are no strange issues with 
modularity that somehow only apply to overloaded operators. UFCS calls 
can never ignore methods of the type. It does not matter how they were 
generated. Was this your strongest point against having the compiler 
combine UFCS and operator call syntax in the straightforward fashion?