Yes there are differences in different proposals. There may be merits in
one or the other or even both. My response hopefully made him aware of past
work and provide references to other work that he may find useful.
We do have late bound polymorphism via member function pointers.
We are likely getting early bound polymorphism via function_ref in C++26.
My proposal improves upon early bound polymorphism not only on function_ref
but also should they ever get proposed, the nary dyno and others.


On Fri, Jan 5, 2024 at 10:23 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Jan 5, 2024 at 10:07 AM connor horman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Member Function pointer can also be a vtable offset and a this
> adjustment. That cannot be converted to a function pointer w/o an object to
> resolve the vptr on. What do you propose happens in this case? A null
> pointer? Undefined behaviour?
>
> The proposal being referenced (which BTW is *different* from the
> proposal that Frederick is pushing) doesn't allow for polymorphism
> with such function pointers. If you say `&SomeClass::member_function`,
> the resulting function pointer *will* call the `SomeClass` version of
> that function. And since it's consteval, its implementation is
> irrelevant; the compile-time member function data structure can
> contain whatever is needed to make this work.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>