On Thursday, 18 January 2024 01:54:33 PST Frederick Virchanza Gotham via Std-
Proposals wrote:
> > 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.

Corollary: if you have an extant object of a given type, then the full type
(once fully constructed) isn't abstract. This is why I said it should be a
pointer to the object instead of a type.

Though both options could be used too: an overload without the type would get
you the devirtualised function pointer for the static type. And then the
compiler can obviously tell you if you're trying to get the address of a pure
virtual. Which *can* exist, BTW, so this may be a legal, albeit incredibly
unlikely scenario.

> Ok then maybe create a new function inside the <typeinfo> header:
>
> namespace std {
> void const *get_polymorphic_facilitator(std::type_info const
> *) noexcept;
> }

Still can't be implemented: there's no link from the type_info object back to
the vtable. The link is one-way and it's from the vtable to the TI.

It would need to be:
    template <typename T> const void *get_polymorphic_facilitator() noexcept;

And we still need some use-cases before considering adding this (at least one
good and two more reasonable). Considering the layout of this type is not
going to be standardised, just what use can you make of a pointer to the
vtable?

This request smells like the X-Y problem: in order to do X (the
devirtualiser), you think you need Y so you're trying to standardise Y. We
should be talking about X instead. And especially because this X function that
uses Y would need to exist inside the standard library anyway because it's not
portable.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering