Date: Mon, 8 Nov 2021 21:28:33 +0000
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_at_[hidden]> 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_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
>>
>
eat up too much syntax.
On Mon, Nov 8, 2021, 20:53 DBJ <dbj_at_[hidden]> 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_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
>>
>
Received on 2021-11-08 15:28:46