That example will scare people away for 2 reasons. Besides the one
presented, there is the awkward ergometric of having to specify the
instance TWICE in memfunc_to_func and invoke_func_as_memfunc which then
leads to the presented problem.

At compile time for KNOWN instance `a` you can call both Base::Go and
Derived1::Go.
At compile time for KNOWN instance `b` you can call both Base::Go and
Derived2::Go.

function_ref allows you to do these same 4 tasks and you don't have to make
Base, Derived1 or Derived2 virtual at all.

function_ref, Dyno and the others are really a better form of polymorphism
that you ?should? defer to 85/90/95/99% of the time.

https://youtube.com/clip/Ugkxo9iqdK7DOY8JCS6hvw9x-P5FqO849zSQ?si=J85Eh-aLJdpgBOqX




On Fri, Jan 5, 2024 at 10:54 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

>
> On Friday, January 5, 2024, Frederick Virchanza Gotham wrote:
>
>>
>> The above code will invoke the 'Derived2::Go' member function on an
>> object of type 'Derived1'.
>>
>
>
> Typographical error:
> Swap 'Derived2' with 'Derived1'.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>