On Thursday, 5 October 2017 at 22:04:10 UTC, Jonathan M Davis
wrote:
It's far cleaner for them to be tied to the type - especially
when you consider that it's not possible to differentiate
between conflicting overloadeded operators.
In other words, we lose global uniqueness of operators if we were
to allow free functions to implement operators.
Knowing which function is called when we see its name is very
important for reading code. That's why we have those anti
hijacking rules: they disallow cases where the compiler knows
that the call can be misleading (or can silently break existing
code). Another, more tricky case is when there are two functions
with the same name in the project you are working on, but only
one of them is being imported. If you read the code, you are
unsure which one is called. The anti-hijacking rules won't work
in that case.
Fortunately, a good naming scheme avoids those problems so they
are not a big problem in practice.
Those problems will pop up, however, if we allow them for
operators. Without further regulations, different
implementations for operators are almost guaranteed, which will
lead to uncertainty and distrust in code using operators.
Besides, I don't how it should work without changes to lookup
rules. How should sum() be able to use a +-operator defined in
an imported module? Not even ADL is helping here.
In my opinion, operators should only be defined in the module
defining the type.
