Operator overloading through UFCS doesn't work

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu May 26 13:15:46 PDT 2016


On Thursday, May 26, 2016 16:24:37 Elie Morisse 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.
>
> Obviously operator overloading should be limited to class and
> struct types, so that's not really relevant.

It's completely relevent, because generic code is frequently going to
operate on a variety of types - including both built-in types and
user-defined types. If code is going to use +, then + must work.
opBinary!"+" is simply not going to cut it. With UFCS, if there's a
potential symbol conflict, then you can work around it - even in generic
code. But with an overloaded operator, the operator must work as an
operator, or generic code simply won't work.

> > UFCS does not have that problem, because you're dealing with
> > free functions and can choose to not use UFCS and provide the
> > full import path or to alias the function, which you can't do
> > with operators - particularly built-in operators.
>
> I still don't understand what you're getting at, unfortunately.

You don't _have_ to use UFCS. You can call the function as a normal free
function with the full import path. You can also alias the function to a
different name and use that with UFCS or import the conflicting function
with an alias so that it doesn't conflict. The overloaded operator, on the
other hand, needs to work as on overloaded operator, and we can't just call
an overloaded operator with its full import path or alias it when
importing it, because it's an overloaded operator and not just a free
function. We have ways to distinguish conflicting types with free functions,
and we don't with operators, because operators were designed to be part of
the type and not free functions. And syntactically, it really doesn't work
to provide a way to distinguish between conflicting versions of an
overloaded operator, because then you're no longer just using the operator
and might as well just be using a function.

But all I'm really doing here is saying the same thing multiple times in
slightly different ways, so if you don't get it, I don't know how to explain
it.

> Thanks for taking the time to explain, although I still fail to
> see a good justification for disabling UFCS for operators. I will
> look for more discussions on the topic and if still no opposing
> argument seems valid I might push the issue forward.

You're going to need more than a good reason why it shouldn't be allowed.
You're going to need a good reason why it should be, and I really don't
think that you're going to have one good enough to get you anywhere with
Walter. I'm fairly certain that there's a thread or two floating around
somewhere in the main newsgroup where he's responded to the issue before
though.

- Jonathan M Davis



More information about the Digitalmars-d-learn mailing list