Ok there is a completely different approach but perhaps a clean solution :

struct Circle {
   float r;
  // spot the new specifier "self"
   float area() self const noexcept { return pi*r*r; } // concise
};

It might be no further explanation is needed; at least on this forum, one
might hope.

On Mon, 8 Nov 2021 at 17:32, Gašper Ažman via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> It has been discussed and rejected *for now*, but the design space there
> has been left open.
>
> There's nothing preventing us from doing something like that in a future
> version of C++.
>
> On Mon, Nov 8, 2021 at 4:30 PM Phil Endecott <
> std_proposals_list_at_[hidden]> wrote:
>
>> Gašper Ažman wrote:
>> > 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.
>>
>> It's the lack of plain access to members without having
>> to write this-> or this. or self. that I regret losing.
>> I.e. I don't want to be able to write "this.foo" in
>> preference to "self.foo" in such a method, I want to be
>> able to just write "foo".
>>
>> I have sometimes wondered whether it would he helpful to
>> provide syntax to bring arbitrary objects' members into
>> scope. Without this, free functions are inherently more
>> verbose than methods. I think that Pascal and/or Modula-2
>> had a "with" statement that allowed this. Example:
>>
>> struct Circle {
>> float r;
>> float area() const { return pi*r*r; } // concise
>> };
>>
>> float area(const Circle& circle)
>> {
>> return pi*circle.r*circle.r; // verbose
>> }
>>
>> float area(const Circle& circle)
>> {
>> with circle {
>> return pi*r*r; // concise
>> }
>> }
>>
>> You'll probably tell me this was considered and rejected years ago...
>>
>>
>> Regards, Phil.
>>
>>
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>