You can do something even more generic, like so:

ˋˋˋcpp

template<auto klass = std::meta::current_class()>
using Self = [: klass :];

struct MyObject {
    void foo(this Self<> self) {};
};

ˋˋˋ

But I dont see a ˋstd::self<>ˋ added to the STL.

Regards,

Le jeu. 3 sept. 2026, 10:16, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> a écrit :

> 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]> 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]> 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]> 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]
> 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
>
>
> --
> Std-Proposals mailing list
> 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
>