
Implementing UFCS for C++ in Clang - foxhill
https://dancrn.com/2020/08/02/ufcs-in-clang.html
======
edsac_xyzw
C++ could adopt the UFCS universal-function-call feature of D-language that
allows any ordinary free function to be called as if they were methods,
without any special kind of type annotation. One of major advantages of UFCS
is that it enhances the discoverability of free functions in IDEs. An user
could write 'Object' followed by dot '.' and the IDE could show all possible
functions applicable to that type. In D-language, the UFCS also works for
primitive types such as int, double and so on.

D-Language UFCS:
[http://ddili.org/ders/d.en/ufcs.html](http://ddili.org/ders/d.en/ufcs.html)
and [https://tour.dlang.org/tour/en/gems/uniform-function-call-
sy...](https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs)

~~~
gpderetta
It could, but it keep getting rejected in committee votes, much to the
frustration of Bjarne.

~~~
mhh__
It's a shame. UFCS is one of the single biggest features that could really
shave off huge amounts of boilerplate. It can also allow you to provide fine
grained type safety where you may not usually be able to (as opposed to
passing _this_ down the chain a la _operator <<_)

------
invokestatic
A common idiom in C APIs is to pass a struct pointer as the first argument to
functions (as sort of a pseudo-thispointer). It would be nice to have this
extension at least simply for syntactic sugar for C interoperability.

~~~
secondcoming
This is exactly what 'this' is in C++, it's a pointer to the class/struct
instance and the compiler inserts it as the first parameter behind the scenes.
There's no difference between a class method and a class static function that
takes a pointer to a class insance as its first parameter.

------
simias
I wish the article included some real-world practical example of when that
would be useful because as it stands I'm very confused. Why not just make your
Extension an other class that would be inherited? Or more simply, why not make
it a member method to begin with?

~~~
1ris
Too much inheritance is widely considered bad OOP. Cross component inheritance
is considered a non-non for some. (e.g. inheriting from QValueList<T>). Most
OOP languages offer a "sealed" of some kind to prevent inheritance because of
this.

Also these functions do not have access to private or protected fields.

It's a way to argument a existing API for your use case without too thight
coupling, whatever that means.

~~~
mehrdadn
This isn't really true in every language. Not every use of inheritance is a
case of OOP. Inheritance is a mechanism used for multiple purposes (especially
in C++) and OOP is merely one of them. It's also just a way to do mixins, and
it's frequently used for that in C++.

------
Teknoman117
on a side note, if you can make extensions for clang that provide new syntax,
I wonder to what extent Qt's moc could be turned into a clang extension.

edit: looks like some people are trying - [https://github.com/woboq/moc-
ng](https://github.com/woboq/moc-ng)

------
kgersen
> The example provided doesn’t have much benefit over the existing free-form
> call (i.e. Extensions.GetValue(what, "nothing") - and this still is also a
> valid way of calling that method).

Extensions.GetValue ?!

------
Ericson2314
This acryonym never made sense here or for Rust (where I think the name came
from>?). "call" means function applications, but the vast majority of the text
is on function declarations.

Fine if new ways of calling things stem from new ways of declaring things, but
then let's please name the feature after the root change rather than it's
ramifications!

\--------

On a different note. I am very excited for C++ to ape Rust features. Please
keep doing it. The end result ought to be a lower marginal cost of Clang
implementing Rust, in which case we can get really good C++ <-> Rust
FFI....and migrate away from C++.

Please, build a bridge from the sinking island.

~~~
jcelerier
> I am very excited for C++ to ape Rust features.

lol, UFCS was discussed in C++ before Rust even existed. Here's a paper from
2003 that mentions it: [https://www.stroustrup.com/N1522-concept-
criteria.pdf](https://www.stroustrup.com/N1522-concept-criteria.pdf)

the committee is pretty much against it so it won't get into "C++" though. but
who cares, clang as a compiler already targets more platforms and has more
eyeballs and development than most other languages anyways.

