The committee actually did look at the (F this) syntax and it took a long
time to convince them that it's a bad idea.

Among the reasons (not all, but enough) - code and tools that assume
`this` is a pointer would get confused. Our old users would get confused.
It clashes with captured [this] in lambdas, `this` is a keyword and now
it's somehow valid as a name in parameter lists? We've never had a
parameter whose name was significant, we'd have to change parameter
definition grammar a lot for that to become useful. We can never decide
that `this` is accessible inside `deduced this` functions (the paper *used
to* have `this` and `self` be able to be accessed and potentially point to
different objects - say operator++(this T x) - `this` would point to
not-the-copy, and `x` would be a copy; but we decided that was really
difficult to teach).

There were other reasons, but the above laundry list is enough.

On Mon, Nov 8, 2021 at 3:31 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, Nov 8, 2021 at 9:42 AM Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Mon, 8 Nov 2021 at 15:30, Phil Endecott via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> > Quoting Marcin's example:
>> >
>> > text_generator_t text(this F self) //no `&`!
>> > {
>> > for (auto c: *(self.p)) co_yield c;
>> > }
>> >
>> > I do wonder why it needs to introduce the parameter name "self",
>> > and can't simply keep the concise syntax in the body, i.e.
>> >
>> > text_generator_t text(F this)
>> > {
>> > for (auto c: *p) co_yield c; // p is this.p
>> > }
>>
>> Because a lambda can have both a deduced-this for the lambda and a
>> captured this from a surrounding
>> class. The solution to that possible confusion is that a deduced-this
>> is never named 'this'.
>>
>
> Also, because `this` is not the "name" of the parameter; it's a modifier
> that changes the calling convention, at both the API and ABI level.
> struct F {
> void one(this F); // called as `f.one()`
> void two(F); // called as `f.two(f)`
> };
> produce different codegen. Neither of those parameters is "named" in the
> function declaration's parameter-list; but one is marked as a "this F"
> parameter while the other is a plain old "F" parameter.
>
> Also, perhaps because the committee looked at your proposed syntax
> text_generator_t text(F this)
> and decided "F this"? :P
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>