Operator overloading through UFCS doesn't work

Elie Morisse via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu May 26 09:24:37 PDT 2016


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.

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

> D was designed to be much cleaner with operator overloading 
> than C++ is. It restricts what the definitions of the operators 
> are so that you don't have to define as many of them to get the 
> basic operations (e.g. opCmp for most of the comparison 
> operators or op!"++" for both pre-increment and post-increment) 
> and so that they aren't easily overloaded to do stuff that does 
> not correspond to what that operator does for built-in types. D 
> doesn't even use + for string concatenation, because Walter 
> thought that that was operator abuse. Allowing arbitrary code 
> to add overloaded operators to an existing type is not at all 
> in line with that philosophy.
>
> Regardless, there really isn't much point in arguing this. If 
> you want things to change, you're going to need to convince 
> Walter, which I very much doubt is going to happen.
>
> - Jonathan M Davis

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.


More information about the Digitalmars-d-learn mailing list