That is what struck me as the obvious answer for the OP's use.
Sometimes it is useful to have a short name for the current class's
type, especially if it is a template, but a "using" declaration like
this should do the job.

One day, I hope, C++ will gain metaclasses something along the lines
proposed by Herb Sutter, to complement reflection. Then ideas like the
OP's can be collected and put together into standard library metaclasses
- all it would take is adding the same "using" clause to the standard
"Class" metaclass, greatly lowering the bar for adding such features and
no language changes would be needed.

In the meantime, I also just write a using declaration when I need
something like this.

David



On 03/09/2026 10:00, Gašper Ažman via Std-Proposals wrote:
> 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
>> <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
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>