Recently I have seen the C++23 proposal P0847R6 ("Deducing this").
When I first started reading that paper, I felt happy, because I thought that the authors were proposing a new, more powerful syntax to define non-static member functions.
However, as I finished reading the paper, my initial happiness had turned into dismay. The paper does not really propose a new syntax for non-static member functions. Instead, it proposes to add to the C++ language a new kind of member functions besides
the existing two kinds, the static and non-static member functions.
The proposed new type of member functions awkwardly merges characteristics of both static and non-static member functions. It can be called with the member-of-object operator like a non-static member function, but it has the type of a static function.
If this paper gets approved, which I doubt it will, it will complicate the C++ language and make it more confusing for no real gain.
All the real benefits of this proposal can be obtained simply by introducing a new syntax for the non-static member functions. There is no need to add to the language a new hybrid kind of member functions.
The only thing in the paper that is impossible to do with the regular non-static member functions is to pass the object parameter by value. But what is the importance of this feature? It hardly has any importance. It certainly does not justify the complicated
and confusing proposal of this paper.
I suggest that the authors take a look at the feature called "extension methods" of the C# language. That feature is very close to their proposal, but it is formulated in a much better and cleaner way. The extension methods of C# are ordinary static functions
that can be defined anywhere, not necessarily in a class scope. They differ from the other static functions only in that they can be called with the member-of-object operator like non-static member functions. Since they are static functions, they can take
the object parameter by value. This system is good because it keeps the distinction clear between the static functions and the non-static member functions. There is no confusing hybridization as proposed in the paper.
In my opinion, this paper should be split into two. One paper should propose an alternative syntax for the already existing non-static member functions, and another should propose a new kind of static functions similar to the "extension methods" of C#. That
way, we keep different things clear and distinct.