Frederick and Thomas,

>From Thomas,








*Not sure if you follow the C++ proposals mailing list religiously but
anyway I implemented your 'direct' member function pointer: First
Implementation:
https://lists.isocpp.org/std-proposals/2024/01/8813.php
<https://lists.isocpp.org/std-proposals/2024/01/8813.php> Second
Implementation Tested with multiple inheritance:
https://lists.isocpp.org/std-proposals/2024/01/8814.php
<https://lists.isocpp.org/std-proposals/2024/01/8814.php>I've even tried
torture-testing it with a very complex web of virtual multiple inheritance,
and surprisingly it still works (even though I can't seen in the assembler
where the 'this' pointer is getting adjusted).*

I really think this needs to be a language feature that is portable.
Programmers shouldn't have to, even with a library, jump through so many
hoops for something that should be there from a completeness standpoint. No
should we hope that compilers will unwind all this goop.
Besides my compile time versus runtime arguments in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2603r1.html,
these are my other reasons.
CFront i.e. C with classes had this in the beginning of C++. It just was
never standardized. There was always a C free function for every member
function. Standard C++ bifurcated member and free functions more by not
completing its design.
Deducing this, while great, bifurcates things more. Regular member
functions are of type "member function pointer" and "Deducing this" member
functions are of type "free function pointer". While free function pointer
is the better of the two choices. There should be a standard way to get a
free function pointer regardless of whether it is a regular member function
or a "deducing this" member function.

Frankly, I don't know what the three of us can do about it. Concerning my
paper, here is the reception to it.

https://github.com/cplusplus/papers/issues/1267

This paper was seen in EWGI in the February 8, 2023
<https://wiki.edg.com/bin/view/Wg21issaquah2023/EWGIP2603R0>evening
session. The following polls were taken.

We are sufficiently motivated by the paper to justify seeing this in
committee again.
SFFNASA
0 0 1 3 3

Result: Not Consensus

EWGI believes the solution to this paper is better done as a cast.
SFFNASA
0 1 2 3 1

Result: Not Consensus

EWGI believes the solution to this paper that is better placed in the
Library.
SFFNASA
1 3 2 0 1

Result: Weak Consensus/Guidance

...

There seems to be no interest in taking some sand paper and rounding off
some of the rough edges of the language even though it does the following.

   1. Reduces bifurcation between member and free functions
   2. Reduces bifurcation between regular member functions and deducing
   this member functions
   3. Makes things more consistent between the runtime and compile time
   calling of functions
   4. Improves performance by removing some of the late binding costs
   5. Doesn't break any existing code as this would just be a new cast that
   didn't exist before
   6. Allows function literals to do exact what is asked of them; important
   for any nary dynamic traits and code adaptability



On Wed, Jan 10, 2024 at 7:05 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Wed, Jan 10, 2024 at 2:21 PM Frederick Virchanza Gotham wrote:
> >
> > Looking at your paper, I've been able to implement the following code of
> yours:
> >
> > Derived derived;
> > void (Base::*bmfp1)() = &Base::some_virtual_function direct;
> >
> > in the following GodBolt on GNU g++:
> >
> > https://godbolt.org/z/1cqbbYfdq
>
>
> Surprisingly, it also works with multiple inheritance -- somehow the
> 'this' pointer gets correctly adjusted but I can't see where that
> happens.
>
> GodBolt: https://godbolt.org/z/TvK5Y7aWh
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>