Type alias or macro approach is not suitable, one is slightly slower in compilation and can't be forgot afterwards, and other one is ugly.
At first I would say "oh it's just a syntactic sugar". However, isn't "if (declaration; condition)" also a syntactic sugar as well?
The main hard reason to reject this feature, is that its only use case is simplifying the name typing. The need in itself is fine. But, it can't solve the long name typing of constructor overloads (i.e. ``Server(Server&& other_server, unsigned mask);``) and the paramter of copy/move assignment. You've gotta solve those inconveniences consistently, either with language feature or with code workaround (the current method is macro, ``#define SELF_ABBREV`` and ``#undef SELF_ABBREV`` after the class definition). Of course, C++ can't 'borrow' Rust's `Self` keyword.
Hence, I would say, accepting this feature would convince people that Modern C++ is becoming more and more jealous of Rust. :-)

Best regards,
Bingzhi.


>Date: Thu, 03 Sep 2026 03:45:04 +0000
>From: Keenan Horrigan <friedkeenan_at_[hidden]>
>To: std-proposals <std-proposals_at_[hidden]>
>Subject: [std-proposals] An abbreviatted explicit object parameter:
> 'struct this'
>I almost always use explicit object parameters in my code instead of using the implicitly-accepted 'this' parameter, because I prefer how then the object parameter gets qualified with const and whatnot in a way that's consistent with every other parameter, and because then I get to work with the object directly, as the value itself or via a reference, which feels to me much more intuitive to read and to use than working with the object through a pointer.
>And I really enjoy doing that, and I like it better than the alternative, but an annoyance which crops up when one uses explicit object parameters everywhere is that the type of the object needs to be repeated everywhere too. This isn't so bad when the type name is on the shorter side, but if the type name is on the longer end, then it can end up hogging a lot of visual space, like the following:
>auto some_method(this const a_kind_of_long_name &self, const another_parameter &param) -> the_return_type {
> ...
>}
>And this annoyance will of course compound with each and every method. Whereas, without the explicit object parameter, this would become:
>auto some_method(const another_parameter &param) const -> the_return_type {
> ...
>}
>Which comes out significantly shorter, but comes with all the other annoyances that I have with the implicit 'this' parameter. The length issue can be somewhat managed by separating out the parameters onto their own lines, or something like that, but ultimately my preference would be to just not need to name the type in this case at all.
>Looking at some prior art in the form of Rust, they allow one to define a method like so:
>fn some_method(&self, param: &another_parameter) -> the_return_type {
> ...
>}
>Where the parameter named 'self' is restricted to being the first parameter, and acts as the explicit object parameter. It is as well specially-blessed such that it can omit its type, defaulting to the 'Self' type, which is injected into scope and which names the same type which the method is called on. But one could explicitly specify it if they wish, like so:
>fn some_method(self: &Self, param: &another_parameter) -> the_return_type {
> ...
>}
>Or a different type than 'Self' may be used, as long as it is meaningfully related to 'Self', such as 'Box<Self>'.
>My *ideal* world would probably have C++ act similarly to Rust in this regard, transforming the initial method into something like this:
>auto some_method(this const &self, const another_parameter &param) -> the_return_type {
> ...
>}
>Where one is able to just completely omit the type. However, I don't think this syntax would be workable, since if we had wanted instead to take the object by value, like so:
>auto some_method(this self, const another_parameter &param) -> the_return_type {
> ...
>}
>Then it's not really clear whether we're accepting an object of the implied 'a_kind_of_long_name' type by value, or if we're accepting an object of type 'self' by value. And there are similar issues with regards to east-const and such, e.g. if we tried a 'this self const &' parameter.
>That could maybe be resolved by making 'self' a special keyword like it is in Rust, but I'm sure that that would result in a breaking change, so of course we'd rather avoid that. We could also try injecting a 'Self' type like Rust does and always specify that, but that similarly would appear to me like it could be a breaking change.
>So, instead, I'd like to float the idea of being able to use 'struct this' (or an equivalent 'class this') to denote the type of a parameter, and to simultaneously mark it as an explicit object parameter. That would transform our original method into something like this:
>auto some_method(const struct this &self, const another_parameter &param) -> the_return_type {
> ...
>}
>The 'struct this' construct would work similarly as the 'Self' type in Rust, where it names the same type which we're defining the method for, except that I would suggest that it only be valid in use with an explicit object parameter. Were it to be valid in other contexts, then one would need to add more cruft onto an explicit object parameter, making it look something like 'this const struct this &self' which I think pretty clearly reads really poorly. Ultimately, what I want is to relieve the paint point of needing to specify the type name for explicit object parameters, as is already the case with an implicit 'this' parameter. I don't feel nearly as strong a desire to omit the type name in other contexts, and so restricting the usage of 'struct this' in that way makes sense to me.
>I would probably prefer the tokens in the reverse, as 'this struct', but that has similar issues as omitting the parameter type completely, as e.g. 'this struct self' could be accepting an object of type 'struct self'. So that wouldn't appear as viable, and so instead I landed on 'struct this', which I think still reads reasonably well.
>What I would like to ask, though, is if there's meaningful interest in adding something like this to the language? And as well, are there any issues with my envisioned 'struct this' that I'm not seeing? I would greatly appreciate hearing your thoughts.
>Thanks