Here is another very interesting case
https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/#comment-2059

struct TaskDescriptor
{
  void submit(this std::unique_ptr<TaskDescriptor> self, const Executor& exec)
  { exec.submit(std::move(self)); }

  // members
};

auto desc = std::make_unique<TaskDescriptor>(...);
std::move(desc)->submit(exec);

Basically the need to call methods not on `this` pointer but on `this`, wrapped inside an object

In a way, this is the reverse of class extensions scenario. There we extend the API of an foreign object, here we create an API for our own object, but we want to call it, having the object be part of another object.
In the end we "extend" the other object, but only as a side effect, not as a primary goal (to have an extended API of the other object).  

As per proposed, the above will be possible, no extra work needed, except, the call site will be:

std::move(desc).TaskDescriptor::submit(exec);

On Thu, Jun 1, 2023 at 5:44 PM Михаил Найденов <mihailnajdenov@gmail.com> wrote:
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.