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
