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
