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
>