| |
 | Posted by Jonathan M Davis
in reply to Steven Schveighoffer |  Permalink Reply |
|
Jonathan M Davis 
| On Wednesday, March 26, 2025 10:59:47 AM MDT Steven Schveighoffer via Digitalmars-d wrote:
> I think we should enable this. It was identified pretty recently in a stream of an influencer (see other messages in this group), as something that is desirable.
>
> Especially with importC, where C does not support operator
> overloading, it should just work. Indeed, in my [raylib
> binding](https://github.com/schveiguy/raylib-d/blob/1cc76b8be3da3c1a34c54528678a62ce237c969e/source/raylib/raylib_types.d#L7), we purposely implement our own copies of all the basic POD types because we want to add operator overloads. This becomes MUCH simpler if we could just use UFCS operators.
>
> A long time ago, member functions were member functions only, and UFCS did not exist (except for arrays). Now that UFCS does exist, and operator overloads are a straightforward template rewrite, the position of only allowing operator overloads to be members is less defendable.
I've been against the idea ever since it was first brought up, and I continue to be against the idea. Overloaded operators are not normal functions, and they're not used like normal functions. Their syntax is fundamentally different, and if there were ever an import conflict because of it, you can't resolve it. At least with UFCS, you can choose to call the function normally instead so that you can give the full import path, but if you do that with an overloaded operator, you might as well not be using an overloaded operator.
Overloaded operators already have a number of restrictions on them to try to enforce that they behave in a sensible way and aren't abused. They're special and IMHO should be treated as such.
I don't want to live in a world where operators start behaving differently based on what was or wasn't imported. They're supposed to be a core part of the type, not just a function that accepts the type.
Imagine the weird side effects that you'd get and hard to track down bugs if something like opCast were overloaded externally.
And some operators clearly can't be overloaded externally - such as opEquals - because the compiler generates the code for them if they're not there. Others simply couldn't work in any sane fashion if they were external (e.g. opDispatch).
IMHO, if you want to add operators to a type, then wrap it. It doesn't require making the language rules any more weird or confusing, and it's straightforward.
- Jonathan M Davis
|
