On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
On Friday, May 27, 2016 09:08:20 Marc Schütz via
Digitalmars-d-learn wrote:
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis
wrote:
> The difference is that it's impossible to do
> 10.opBinary!"+"(15), so if you're forced to do
> foo.opBinary!"+"(bar) to get around a symbol conflict, it
> won't
> work with built-in types.
Well, that begs the question: Why don't built-in types define
`opBinary`? That's just another arbitrary irregularity, isn't
it.
It was never intended that any op* function be called by anyone
except where the compiler lowers code to use them. They're for
declaring overloaded operators on user-defined types so that
those types can be used with those operators. If you're calling
opBinary in your own code, you're doing it wrong. And it would
be downright silly to then add opBinary to the built-in types.
If I were to design my own language from scratch, that's actually
how I would do it. All operators, even for built-in types, would
just be syntax sugar for the method calls. The goal should be to
minimize the difference between built-in and user-defined types
as much as possible. Turtles all the way down...
They don't need operator overloading. They already have the
operators. Operators are supposed to be used as operators, not
functions, and if there's any need to use them as functions,
then there's something seriously wrong. And the fact that
allowing free functions to overload operators via UFCS sends us
into that territory just highlights the fact that they're a
horrible idea.
I'd say the fact that it doesn't work, and can't currently work
for the reasons you described, points to an inconsistency in the
language's design. It means that we have two largely overlapping
concepts (builtin types and user defined types), where most
language features work the same for both, but some don't.
That's not the end of the world, of course, but still...
