Operator overloading through UFCS doesn't work

Marc Schütz via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon May 30 08:15:31 PDT 2016


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...


More information about the Digitalmars-d-learn mailing list