> On 30 Apr 2025, at 20:32, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Wed, 30 Apr 2025 at 20:59, Hans Åberg <haberg_1_at_[hidden]> wrote:
>
>>> And it has the advantage over a polymorphic
>>> cloning function that a polymorphic cloning function needs
>>> to decide how the object is allocated, whereas for use with
>>> std::polymorphic, all your type needs to be is to be copyable,
>>> and various different allocation strategies can be employed. That
>>> makes the combination more flexible, while requiring
>>> much less from your type A. You get polymorphic copies and the base
>>> interface, and all you need to opt in to that is to
>>> make your type copyable.
>>
>> I have only had the need for different allocation strategies with GC references: different forms of reference counting, and Boehm GC.
>
> Right, but if you ever need it, you can just use it without any extra
> work on your type A. Maybe you'll need it one day, maybe someone
> who (re)uses your code will need it, maybe either of those audiences
> needs to slot in a debug allocator at one point. The advantage
> is already there, and you don't need to do anything in your type A to
> benefit from it.

I added a conversion from std::variant<B...> to my val<A> type with the idea of using it in a Bison C++ typed parser, but it failed on the use of dynamic_cast, which requires all B... to be virtual polymorphic. This does not work because not all parser types are derived that way.