Date: Mon, 2 Aug 2021 21:33:09 -0400
On Mon, Aug 2, 2021 at 7:41 PM Hani Deek via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> The non-static member functions which we have now do not accept the 'implicit object argument' by value. It has to be passed by reference. If the proposal will simply introduce a new syntax to define that kind of functions, then the proposed syntax shouldn't allow the object parameter to be non-reference. If you do that, you should not run into any kind of problems with regard to the type of the function pointer.
OK, so let's look at this.
You want to discard literally every use case of this feature *except*
deduplication of `const` or other qualified parameters. You want a
feature focused specifically on just that. It's still going to have to
use templates to generate the various overloads, but you want it to
only work in that use case. So we give up recursive lambdas, better
CRTP, by-value members, SFINAE-friendly callables.
And in exchange, we get...
What?
Tell me. We get what? Fewer pages in the standard? In a standard that
already has eighteen *hundred* pages, we would have... *two* fewer
pages.
Because if what you care about is standard "complexity", it's *really*
just that. Go look at the current wording in P0847. It's incredibly
*short*. Most of its changes are turning "non-static member function"
into "implicit object function", a mere text replacement. There are a
couple of big blocks of text, but none of these are more than a single
page.
Also note that in this wording, explicit object functions are
considered non-static even though their function pointers are not
member pointers.
<std-discussion_at_[hidden]> wrote:
>
> The non-static member functions which we have now do not accept the 'implicit object argument' by value. It has to be passed by reference. If the proposal will simply introduce a new syntax to define that kind of functions, then the proposed syntax shouldn't allow the object parameter to be non-reference. If you do that, you should not run into any kind of problems with regard to the type of the function pointer.
OK, so let's look at this.
You want to discard literally every use case of this feature *except*
deduplication of `const` or other qualified parameters. You want a
feature focused specifically on just that. It's still going to have to
use templates to generate the various overloads, but you want it to
only work in that use case. So we give up recursive lambdas, better
CRTP, by-value members, SFINAE-friendly callables.
And in exchange, we get...
What?
Tell me. We get what? Fewer pages in the standard? In a standard that
already has eighteen *hundred* pages, we would have... *two* fewer
pages.
Because if what you care about is standard "complexity", it's *really*
just that. Go look at the current wording in P0847. It's incredibly
*short*. Most of its changes are turning "non-static member function"
into "implicit object function", a mere text replacement. There are a
couple of big blocks of text, but none of these are more than a single
page.
Also note that in this wording, explicit object functions are
considered non-static even though their function pointers are not
member pointers.
Received on 2021-08-02 20:33:23