struct Circle {
   float r;
  // spot the new keyword "self"
  // concise but prone to abuse?
   float area() const noexcept { 
     self {
       return pi*r*r; 
     }
   }  
};

On Mon, 8 Nov 2021 at 22:28, Gašper Ažman <gasper.azman@gmail.com> wrote:
Has been suggested and rejected. Free identifiers after the parameter list eat up too much syntax.

On Mon, Nov 8, 2021, 20:53 DBJ <dbj@dbj.org> wrote:
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@lists.isocpp.org> 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@chezphil.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals