On Tue, Jun 10, 2025 at 5:30 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Tue, Jun 10, 2025 at 12:07 AM Oliver Hunt <oliver_at_[hidden]> wrote:
> >
> > Not sure of the MS implementation, but in stdlibc++ and libc++
> > __dynamic_cast assumes that the source type_info and the object has
> > already been adjusted to support the path to the target type.
>
>
> If needed, I'm happy to take the implementation of '__dynamic_cast'
> from those libraries and tweak it if needed. But it might work as is,
> I'll test and see.
>
>
> > The fundamental problem that you seem unwilling to understand that the
> > c++ type system does not have a polymorphic bottom type, and what you’re
> > doing is essentially trying to create one by hacking around assumptions in
> > the type system.
>
>
> I don't know if you're a Star Trek fan, but in Picard's words:
>
> "Space: the final frontier. These are the voyages of the
> starship Enterprise. Its continuing mission: to explore strange
> new worlds; to seek out new life and new civilizations; to
> boldly go where no man has gone before!"
>
> On the day that I discovered on the GNU g++ compiler that the vtable
> pointer is always at address [base + 0x00] in any polymorphic object,
> I started to explore. And I started to realise that a lot more is
> possible with polymorphic objects than the C++ Standard is letting on.
> I'm happy to learn little by little here, and to add more and more to
> 'polyhandle'. It was actually only yesterday that I started thinking
> that maybe I could perform a 'dynamic_cast' from a ' void * '. (Note
> that that previous sentence says 'from' instead of 'to').
>
> As you said, C++ hasn't got a polymorphic bottom type. So let's say
> that I'm writing a program that uses wxWidgets for some of the
> windows, and Qt for some of the other windows. Let's say I have a
> global container of all the windows in my program:
>
> std::vector< polyhandle > g_all_windows;
>
> It would be good if I could, at runtime, check if it's a QWindow or a wxWindow:
>
> for ( polyhandle p : g_all_windows )
> {
> if ( p.dynamicCast<QWindow> ) DoSomething();
> else if ( p.dynamicCast<wxWidget> ) DoSomethingElse();
> }

This is kind of why motivation sections need to exist. This use case
is already covered by existing standard library types. You could
easily have used `std::any` or `std::variant`. `any` would be more of
an exact fit, but `variant` would probably be nicer to use (especially
with pattern-matching). Others have mentioned specialized polymorphic
type-erased class proposals.

What this means is that the only thing your proposed "polyhandle" type
provides that we don't already have is... being smaller. And *maybe*
faster (though in the pattern-matching case, I genuinely doubt it,
unless what you're going to do with that pointer is an actual dynamic
cast).

So you need to explain why that matters enough for the committee to
standardize this type. That is, if someone needs this functionality,
is it in performance critical code where being exactly one pointer in
size is critical functionality? And if it is, does it happen often
enough to be worth standardizing?

This intersection of functionality and performance just doesn't seem
significant enough to standardize.