Not to mention, you've got (at least) two incompatible name mangling ABIs,
and I doubt very much that either will want to break basically every one of
their users by so radically altering their definition.

On Sun, 14 Jan 2024 at 18:55, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Jan 14, 2024 at 6:28 PM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Sat, Jan 13, 2024 at 7:04 PM Jarrad Waterloo wrote:
> > >
> > > I really think this needs to be a language feature that is portable.
> >
> >
> > I agree that it should be a portable language feature in C++26,
>
> What is "it"? Because the two of you are talking about two
> *fundamentally* different things here.
>
> You want to get a free function pointer that behaves exactly like the
> memer pointer does. Jarrad's proposal *is not that*.
>
> Jarrad's proposal is to convert a member function pointer into a free
> function pointer that calls *exactly* the member function that was
> specified in the expression that extracted the member pointer. That
> is, no virtual dispatch.
>
> These aren't the same thing. You would not get what you want from
> Jarrad's proposal and vice-versa.
>
> > And while I'm talking . . . maybe it would be worth mentioning that
> > name mangling should be standardised too?
>
> I'm going to ignore the fact that this is a core ABI issue and
> therefore cannot ever be standardized and instead ask a different
> question. From a standard perspective... what is "name mangling"?
> Like, what would it mean?
>
> Name mangling is an implementation detail used to allow ABIs designed
> for C to work with C++ function overloading, namespaces, and the like.
> That's it. C++ has features that allow two entities to have the same
> name yet are different. C ABIs can't handle that. Name mangling is how
> they square that circle. It is completely invisible to a user writing
> standard C++.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>