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