On Sat, Jul 31, 2021 at 12:28 PM Hani Deek via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> > OK, so what would this "new syntax" look like?
>
> I have no problem with the syntax that is proposed by the paper. I said that that syntax made me happy when I first saw it, because I thought it was meant to define non-static member functions. It would be logical to use that syntax for that purpose. However, as I progressed in the paper I realized that the proposed syntax was not meant to define non-static member functions but rather a new kind of member functions.
>
> The problem is not with the proposed syntax but with the use that the paper proposes for that syntax.
>
> It is impossible to be a good C++ programmer without understanding the concepts that underly the language.

I don't buy that, in general. There are levels of understanding of
certain features that are useful to a C++ programmer, and there are
things where if you know about them, you know entirely too much about
the language. I don't believe you have to understand every facet of
function overload resolution or template meta programming and
instantiation gymnastics to be a good C++ programmer. You need to know
some of it, but if you don't want to go into the deep, dark recesses
of the language, you can still get your work done.

And for this case in particular, the only thing that's likely to trip
up a C++ programmer is accidentally expecting to get a
pointer-to-member when you reference one of these functions. And it's
easy enough to temper your expectations once you get the appropriate
compile error.

> Understanding those concepts becomes easier if people avoid making them more complex for no good reason.

I don't understand where the complexity comes in. This syntax is, at
its most complex, an alternative way to define a static member
function, but with some syntactic sugar associated with it when you
call it non-statically (ie, its first parameter is the object you're
calling it on).

This does not seem particularly novel. The most complicated thing
about it is that these functions overload with, and therefore can
conflict with, non-static member functions and their *implicit*
parameters. And that's not all *that* complicated.

> In the current C++ format, the "implicit object parameter" and the "this pointer" are concepts associated with the non-static member functions. There are no implicit object parameter or this pointer for static functions. Also the two types of member functions produce different results when one uses the decltype operator on their expressions.

Let's examine that last point.
`decltype(SomeTypename::some_func_name)` will result in a different
type depending on whether it is static or non-static. It will either
be a pointer-to-member-function or a function pointer. Therefore, a
user using this construct, or some equivalent, will need to know what
kind of function that is.

This proposal doesn't add some third possibility. The result will
still either be a pointer-to-member-function or a function pointer. If
`some_func_name` uses this new syntax, it will result in a function
pointer which can be used in *every way* that existing function
pointers (of the given signature) can be used.

As previously stated, the only "complexity" is that you didn't use the
keyword `static` when you declared it.

> The P0847R6 proposal messes up those fundamentals for no good reason. It disrupts the current format in order to achieve something that can be achieved differently without any disruption.

Oh, and one last thing. P0847 has already been approved by EWG and CWG
(https://github.com/cplusplus/papers/issues/115). It's up for review
by Plenary, so it's almost certainly going to be in C++23. There was
*one person* who voted against forwarding it to CWG from EWG. So
you're a bit late to the party.