Date: Wed, 22 Jul 2020 09:55:44 -0500
On Wed, Jul 22, 2020 at 9:46 AM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Wed, Jul 22, 2020 at 6:34 AM Gašper Ažman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> The *new* version of the wording makes the wording far more clear (could
>> have sworn we sent it in a mailing, but I guess we'll have to send it
>> again):
>>
>> https://htmlpreview.github.io/?https://raw.githubusercontent.com/BRevzin/cpp_proposals/master/0847_deducing_this/d0847r5.html
>> is the status quo of the paper. There are no design changes or semantic
>> woding changes, just Jens', Barry's and my wording refactors.
>>
>> The relevant bits:
>>
>> 5b A function parameter declared with an
>> *explicit-this-parameter-declaration* is an *explicit this parameter*.
>> An explicit this parameter shall not be a function parameter pack
>> ([temp.variadic]). An *object member function* is either a non-static
>> member function or a static member function with an explicit this parameter.
>>
>> Change 12.6.4 [over.sub] <https://wg21.link/over.sub>/1:
>>
>> 1 A *subscripting operator function* is a function named operator[] that
>> is a non-static an object member function with exactly one ordinary
>> member parameter.
>>
>> See, now *this* I would call a separable bit of the proposal! :)
>
Given that there are multiple motivating examples in the paper that rely on
this, no.
> Do you know if there are any proposals in-flight, or any proposals
> recently rejected, to get rid of the asymmetries around some of the
> operators and permit e.g. operator[] and operator() to be free functions?
>
> struct S {
> // Current: operator[] cannot be a non-member function
> friend Element& operator[](S& lhs, int rhs) { return lhs.data_[rhs]; }
> };
>
> Or even to permit operators to be static member functions?
>
P1169 was rejected.
Barry
>
> struct Comparator {
> // Current: operator() cannot be a static member function
> static bool operator()(int x, int y) const { return x < y; }
> };
>
> –Arthur
>
std-proposals_at_[hidden]> wrote:
> On Wed, Jul 22, 2020 at 6:34 AM Gašper Ažman via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> The *new* version of the wording makes the wording far more clear (could
>> have sworn we sent it in a mailing, but I guess we'll have to send it
>> again):
>>
>> https://htmlpreview.github.io/?https://raw.githubusercontent.com/BRevzin/cpp_proposals/master/0847_deducing_this/d0847r5.html
>> is the status quo of the paper. There are no design changes or semantic
>> woding changes, just Jens', Barry's and my wording refactors.
>>
>> The relevant bits:
>>
>> 5b A function parameter declared with an
>> *explicit-this-parameter-declaration* is an *explicit this parameter*.
>> An explicit this parameter shall not be a function parameter pack
>> ([temp.variadic]). An *object member function* is either a non-static
>> member function or a static member function with an explicit this parameter.
>>
>> Change 12.6.4 [over.sub] <https://wg21.link/over.sub>/1:
>>
>> 1 A *subscripting operator function* is a function named operator[] that
>> is a non-static an object member function with exactly one ordinary
>> member parameter.
>>
>> See, now *this* I would call a separable bit of the proposal! :)
>
Given that there are multiple motivating examples in the paper that rely on
this, no.
> Do you know if there are any proposals in-flight, or any proposals
> recently rejected, to get rid of the asymmetries around some of the
> operators and permit e.g. operator[] and operator() to be free functions?
>
> struct S {
> // Current: operator[] cannot be a non-member function
> friend Element& operator[](S& lhs, int rhs) { return lhs.data_[rhs]; }
> };
>
> Or even to permit operators to be static member functions?
>
P1169 was rejected.
Barry
>
> struct Comparator {
> // Current: operator() cannot be a static member function
> static bool operator()(int x, int y) const { return x < y; }
> };
>
> –Arthur
>
Received on 2020-07-22 09:59:15