On Thu, Jan 18, 2024 at 4:04 AM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
> > CHANGE 1: The type 'std::type_info' needs a new consteval static
> > member function called 'get_polymorphic_facilitator' which returns a
> > pointer to the class's vtable. (It returns a nullptr is
> > !std::is_polymorphic_v<T>). The C++ Standard won't need to mention the
> > word 'vtable', it can just say "polymorphic facilitator" and leave its
> > implementation as unspecified.
> >
> > CHANGE 2: The standard library needs a new standalone constexpr
> > function called 'std::devirtualise' which changes a 'virtual' pointer
> > to a 'direct' pointer, which on GNU g++ would be implemented something
> > like:
>
> Change 1 can be skipped if the devirtualize function takes a pointer to the
> object whose vtable you want to read.


If the base class is abstract (i.e. has some virtual functions marked
"= 0"), then you won't be able to give it an object of type Base.


> That's important because Change 1 is not
> implementable, as none of the type_info objects today have a link back to the
> vtable, and such a link cannot be added without an ABI incompatibility.


Ok then maybe create a new function inside the <typeinfo> header:

    namespace std {
        void const *get_polymorphic_facilitator(std::type_info const
*) noexcept;
    }

This function will return a nullptr if the 'type_info' refers to a
type that is !std::is_polymorphic_v<T>.


> The library function will likely be implemented as an intrinsic, because the
> compiler knows where in the object the vtable pointer is located.


Yeah probably something like:

    namespace std {
        inline constexpr void const
*get_polymorphic_facilitator(std::type_info const *const arg) noexcept
        {
            return __get_polymorphic_facilitator(arg);
        }
    }