Hello, with explicit object parameter we can have mixins as such:

struct StringUtils {
  template<class T>
  void contains(this T self, char) { ... }
};

class MyString : public StringUtils {
 ...
}

We can also have half-baked extensions as such:

struct StringUtils {
  void contains(this class MyString& self, char);
};

class MyString : public StringUtils {
 ...
}

void StringUtils::contains(this MyString& self, char) { ... }

This is *almost **usable*. The fact that we need to subclass kills any
perceived advantage as the extension becomes part of the
implementation, making it no longer an extension.
One is still better off writing a class-static function to get the extra
functionality.

This can be improved by allowing to *call * *StringUtils methods, which
have the correct type of the `this` param or it is a template, without
subclassing from it!*

class MyString {
 ...
}

struct StringUtils {
  void contains(this MyString& self, char) { ... }
};

int main() {
  MyString s = "hello";

  s.::StringUtils::contains('e');

  return 0;
}

I am using the fully qualified access to show, there is *at least one* syntax
that is *perfectly safe. *It might not be very practical, but it is a
start.
We can argue how we can improve it, what are the chances, subclasses can
have the same name and/or what happens if other utilities are already in
use. But at least with that particular syntax, no issues will ever arise.
(Of course a performance argument can be made - now after the dot, many
more classes become candidates, but it's a start...)

And no, there is no UFC proposed.
Just making use of the fact, the *explicit object parameter **already **does
not point to a separate (new, with the introduced type) state! This is *
*fundamentally** different then regular methods and the reason why this
kind of classes **do not need subclassing **to be used by other classes. *All
state is already defined by an external class, being a child of that class
does not bring a structural difference.