Hi,

I don't like that this is implemented as essentially a specialization of variant. There is no reason that variant<Cat, Dog> and variant<specify_base<Animal>, Cat, Dog> should be different types. They are essentially the same thing with the same layout. If you have distinct interfaces that specify these two types, then you might end up needlessly moving or even copying when gluing them.

At most this should be a facade over variant, with access to the underlying variant, when needed. But I prefer a convenience function over a variant even more.

As for the implementation I believe there could be potential cv-correctness issues if varant holds cv-qualified alternatives. I believe variant<const Cat, Dog> is valid, you should not be able to get a non-const Animal pointer out of this.

Finally this whole thing feels a bit wrong for me. This is a weird mixture of two kinds of dynamic polymorphism when one would be enough. In the end you pay for both kinds of dynamic dispatch, although hopefully the compiler can optimise the virtual call out. Even then, why pay both for a type discriminator plus a vtable pointer when you (hopefully) don't even use the vtable pointer?

Cheers,
Lénárd

On 14 September 2022 19:37:52 BST, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:
>I have written a draft paper for my suggestion to augment std::variant
>so that it can be used like a pointer to a Base class:
>
> http://www.virjacode.com/variant_common_base.pdf
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals