I think there would be more of a rationale for this if we said

Memfunc pointers are when you care about doing right by
virtual/base-to-derived dispatch.

You should be able to get a free function pointer to that asm stream
without the above functionality. It's monomorphized at that point.

I think that might work as an argument - I have two papers ("replacement
function" and "calltarget") that might benefit from this facility.

It also kinda intersects with "member function pointers are just callables".

On Sat, Jan 13, 2024, 19:04 Jarrad Waterloo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>