Menu
Search

Forums

Forums

Forum Index

Jump to page: 1 2 … 4  
Page
Thread overview
operator overloading outside the type
Mar 26
Meta
Mar 26
bauss
Mar 27
monkyyy
Mar 27
Ogion
Mar 28
sfp
Mar 28
Dukc
Mar 28
sfp
Mar 29
sfp
Mar 30
sfp
Mar 30
ltdk
6 days ago
Mengu
5 days ago
Dukc
Apr 01
sfp
Mar 29
sfp
Mar 29
Araq
March 26
Gravatar of Steven SchveighofferPosted by Steven SchveighofferReply
Steven Schveighoffer
Gravatar of Steven Schveighoffer


Reply

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, 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 also agree with the streamer that .h files should just work.

-Steve

March 26
Gravatar of Paolo InvernizziPosted by Paolo Invernizzi
in reply to Steven Schveighoffer		Reply
Paolo Invernizzi
Gravatar of Paolo Invernizzi
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer wrote:

>

I think we should enable this.

..snip..

>

I also agree with the streamer that .h files should just work.

+1

March 26
Gravatar of MetaPosted by Meta
in reply to Steven Schveighoffer		Reply
Meta
Gravatar of Meta
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer 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, 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 also agree with the streamer that .h files should just work.

-Steve

Yes, let's Just Do It™

March 26
Gravatar of baussPosted by bauss
in reply to Steven Schveighoffer		Reply
bauss
Gravatar of bauss
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer 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, 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 also agree with the streamer that .h files should just work.

-Steve

+1

March 26
Gravatar of Paul BackusPosted by Paul Backus
in reply to Steven Schveighoffer		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer 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, 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.

I'm not opposed to this on principle, but I expect it will run into considerable pushback from Walter. Probably not a battle worth fighting.

>

I also agree with the streamer that .h files should just work.

+1000. This is literally the number-one thing that ImportC needs to get right. The fact that it doesn't work is an embarrassment.

March 27
Gravatar of monkyyyPosted by monkyyy
in reply to Paul Backus		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to Paul Backus


Reply

On Wednesday, 26 March 2025 at 21:22:18 UTC, Paul Backus wrote:

>

Probably not a battle worth fighting.

Sometimes you should fight for its own sake

March 27
Gravatar of Elias Batek (0xEAB)Posted by Elias Batek (0xEAB)
in reply to Paul Backus		Reply
Elias Batek (0xEAB)
Gravatar of Elias Batek (0xEAB)
Posted in reply to Paul Backus


Reply
On Wednesday, 26 March 2025 at 21:22:18 UTC, Paul Backus wrote:
>> I also agree with the streamer that .h files should just work.
>
> +1000. This is literally the number-one thing that ImportC needs to get right. The fact that it doesn't work is an embarrassment.

That reminds me of something…
Check out slide 11–13 of <https://dconf.org/2021/online/slides/bright.pdf>.
March 27
Gravatar of OgionPosted by Ogion
in reply to Steven Schveighoffer		Reply
Ogion
Gravatar of Ogion
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer 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.

Maybe only for structs and classes and not for something like int.

March 28
Gravatar of sfpPosted by sfp
in reply to Steven Schveighoffer		Reply
sfp
Gravatar of sfp
Posted in reply to Steven Schveighoffer


Reply

On Wednesday, 26 March 2025 at 16:59:47 UTC, Steven Schveighoffer 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, 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 also agree with the streamer that .h files should just work.

-Steve

I would REALLY, REALLY like this feature to be implemented.

I said my bit about it over in the other thread about the stream since I didn't notice this thread:

https://forum.dlang.org/post/azieoqhwwgployarvazx@forum.dlang.org

I also read through this old thread:

https://forum.dlang.org/thread/mntbbmllhxgdmwynffpz@forum.dlang.org?page=1

and as far as I can tell there is no real technical impediment to adding this feature.

March 28
Gravatar of Jonathan M DavisPosted by Jonathan M Davis
in reply to Steven Schveighoffer		Reply
Jonathan M Davis
Gravatar of Jonathan M Davis
Posted in reply to Steven Schveighoffer


Reply
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
« First   ‹ Prev
1 2 3 4
Next ›   Last »