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?
