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
>