Implementing UFCS for C++ in Clang

It really couldn't. It would be a breaking change.

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.

You may not be the author/maintainer of that class.

> Why not just make your Extension an other class that would be inherited?

Because now I have a down casting issue (especially when talking about non-heap "objects"). Which means implementing and forwarding dozens of methods, and/or sloppy bug-prone (when some other developer puts variables on the class without noticing) implicit casts.

> I wish the article included some real-world practical example of when that would be useful

The classic one is interface helpers. Methods which smooth out the usage of an interface but are not relevant to the implementation of it. Yes one can put those methods on the interface's definition. But this allows separating where the interface is declared (some header some where) and where the code for it is defined (some code file), potentially across libraries (e.g. a header only "library" of interfaces, and a utility library of methods for making it nice to use). Notably this also avoids some frustrating header shenanigans and allows writing interface helpers against concrete types to come up with a more natural library organization.

The next one is it much easier to write "literate programming" style code in C++ (which is nice because they often make types "disappear" in their usage, and many argue provide more readable code as a consequence). A problem many developers currently solve with operator overload (see `<<` for the C++ standard printing library). This also makes it way way easier for such literate programming to be extensible (believe me I wrote the templates for extensible literate programming once, it's insanely painful).

Also, depending on how these implement templates, they might be a much more appreciated method of adding optional class methods to templates by making the method a compile error to call in the first place ("missing method") rather than a substitution failure error ("<massive call stack>").

  seperator.join(iterable)
  "".join(["foo", "bar", "hello"]) # => "foobarhello"
  ", ".join(["Hacker News", "Twitter"]) # => "Hacker News, Twitter

https://mail.python.org/archives/list/python-ideas@python.or... https://mail.python.org/archives/list/python-ideas@python.or... https://mail.python.org/archives/list/python-ideas@python.or... https://mail.python.org/archives/list/python-ideas@python.or...

`["a", "b", "c"].join(iterable)` was rejected because it forces every iterable to implement iterable functions.

Additionally some iterables, like generators, are mutated when you iterate over them:

  ", ".join(streaming_api.fetch_names())

NaN guarding:

  import std.traits;
  auto unwrap(T)(T input) if (isFloatingPoint!T) {
      // Asserts cost nothing when turned off with -check=assert=off
      // The compiler can fully inline this function, so it isn't expensive
      assert(input !== input.nan);
      return input;
  }

  if (objSize.unwrap < cellSize) {
     // Allocate a new cell for the object
  } else {
     // Insert into current cell
  }

  if (objSize.unwrap() < cellSize) {
     // Allocate a new cell for the object
  } else {
     // Insert into current cell
  }

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

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.

And of course rust people found a way to make this all about rust. I highly doubt the Clang devs are thinking "hmm we're really close to compiling rust but we just can't figure out UFCS." And C++ is not at all a sinking island.