slopfront
Reddit, read-only. No JavaScript. No cookies. No tracking.
preferences

Implementing UFCS in Clang

46 points · submitted Aug 2020 by u/Pazer2

10 comments · 94% upvoted · source · other discussions

comments

fdwr 9 points · Aug 2020 · fdwr@github 🔍

Would love this. There are so many times when a class (which I can't modify) is missing some really convenient method, and so I end up either:

  • Adding a number of loose helper functions, but they just aren't the same, with an inside out call sequence rather than a nice left-to-right reading flow of object and then modification of that object.
  • inheriting from the the thing just to add some methods, which ruins the ability to cleanly pass the original object type around as a parameter because it's no longer the original type. 😢
germandiago 1 points · Aug 2020

True but... IDE completion?

Not sure how reliable. Anyway, eith modules things should be ok.

fdwr 3 points · Aug 2020 · fdwr@github 🔍

IDE completion?

Yes please 😄.

TheThiefMaster 16 points · Aug 2020 · C++latest fanatic (and game dev)

UFCS is not extension methods. That's something else.

UFCS is allowing common calling syntax for both member and non-member functions. Extension methods are additional syntax for a 3rd kind of function...

qoning 6 points · Aug 2020

Well, in the common definition, ufcs allows for what is commonly referred to as extension method syntax. That doesn't mean it's identical to something like C#, the big difference is of course that with ufcs, you are still allowed to call it as a free function.

HellAndCo 3 points · Aug 2020

Extension methods in C# can also be called with the "free" syntax (as free as functions can get in C#).

see: https://dotnetfiddle.net/Widget/pT3sso

konanTheBarbar 3 points · Aug 2020

I would love to see this. Seems like a good compromise - it's not exactly classic UFCS, but lets you basically do the same. I like it.

tpecholt 2 points · Aug 2020

I think extension methods are not very appealing in c++ because the STL way for extensibility is to prefer free functions instead of member functions syntax. Recent language development like ranges operator| and |> also follow that pattern.

Pazer2 [OP] 22 points · Aug 2020

I would argue that (ab)using operator| like this is a workaround for not having extension methods. Having proper extension methods helps a lot with discovery, and makes chaining together long sets of operations much more readable than calls(function(nested())).

Ameisen 8 points · Aug 2020 · vemips, avr, rendering, systems

I concur with this.

I'd much rather have extension member functions than free functions for everything. I'm also not particularly fond of ranges syntax.