Or more generic   using self_t = [: std::meta::current_class() :];   -----Ursprüngliche Nachricht----- Von:Gašper Ažman via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 03.09.2026 10:01 Betreff:Re: [std-proposals] An abbreviatted explicit object parameter: ‘struct this‘ An:std-proposals_at_[hidden]; CC:Gašper Ažman <gasper.azman_at_[hidden]>; Valid gripes, but in my experience, "fixing the language" (or, in other words, add even more special cases to the language) just to save a few characters is rarely worth it. There just isn't enough ROI.  So, what I do is   struct my_long_type_name {     using self_t = my_long_type_name;     auto foo(this self_t const& self) -> int { return 0; } };  and be done with it.  G On Thu, Sep 3, 2026 at 5:41 AM Keenan Horrigan via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: The template version isn't equivalent. It will deduce to a different type depending on which possibly-derived type the caller has available to them, and so the member accesses and all can lead to different behavior. And if one were wanting to declare a mutable method that way, it would end up like so:  void method(this auto &self)  Except that that can be called with a const object, with the 'auto' deducing to 'const whatever_type', which would presumably lead to a compiler error, but without it being e.g. checkable by a concept since it doesn't fail to find an overload.  I also tried to explicate that I'm not suggesting adding 'self' as a keyword, maybe I didn't do that well enough. That would appear to me as a breaking change, and yes in the event that it were made a keyword then one wouldn't even need the 'this' keyword there.  And the implicit member access isn't even my primary annoyance with the implicit 'this' parameter, though I do think it poor. For me, the primary benefit of the explicit object parameter is that it makes treating with the object that the method was called on consistent with every other object that one treats with. It just becomes much more intuitive and expressive in my experience, most strongly so when e.g. using an operator on the 'this' object, which can require some dereferences of the 'this' pointer otherwise and which just clashes a lot with everything else.  What I would like though is a way to abbreviate the common case of accepting the same type for which the method is being defined. On Wednesday, September 2nd, 2026 at 11:22 PM, Light And Ray via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: If you can use templates, and I see you're already using auto in some examples, you can use auto instead of type  void method(this const auto& self)  If we'll have a keyword denoting the class of this, it will cause ambiguity in case of polymorphism  Also, you are suggesting adding "self" as a new keyword. But we already have keyword/magic variable "this". In your proposal, we can just ommit both the type and the identifier  I personally don't see a problem with implicit this. You can think of it like the class is a namespace, and inside this namespace you can use variables and functions without writing the namespace. In pair with naming conventions where you should name private members with some sort of suffix/prefix, there is no problem at all to see what variables are local, and what are members On Thu, 3 Sept 2026, 07:45 Keenan Horrigan via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: 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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals