On Monday 15 April 2024 00:45:17 GMT-7 Mihail Mihaylov via Std-Proposals
wrote:
> The base class can be polymorphic, while the derived class can be final and
> copyable. Consider a base abstract interface class which has multiple final
> copyable implementation classes. The "sender" can store into the `any` an
> instance of the copyable derived type and the receiver could extract a base
> pointer or base reference to the contained value.

What are sender and receiver here?

Since you didn't specify and it wasn't part of the discussion, I'm going to
assume it refers to Qt signals. In that case, this use-case doesn't make
sense: you identify the sender by its pointer address, not by a copy of it.
QObect are not copyable so they can't be put inside of a std::any.

A pointer to a QObject can. But then the solution is simple: you store the
pointer to the QObject and allow dynamic_casting or qobject_casting to the
user's desired type to see if it is such or not.

> This is very common when we are using non-erased types, so I believe it's
> perfectly reasonable to want it with erased types too. And the only reason
> Jason had me convinced for a moment that this is not reasonable for
> `std::any` specifically, is because he made me believe that `any_cast`
> always copies the value, which is not true.

I do not. This use-case is already solved by a pointer to the base class. I
don't see why std::any needs to support the casting if you can simply use the
pointer itself. And I definitely don't see why you should need to store the
full object inside of std::any.

> > It does support storing pointers and, if the pointer is to a class derived
> > from QObject, then it can perform casting back to QObject and to any other
> > class that derives from it after verifying that this cast would be valid.
>
> Please, note that in the example above, we are not storing a pointer, we
> are storing a `Derived` value, and `std::any` allows us to extract a
> `Derived *` to it. What we want is to be able to extract a `Base *` pointer
> to it. Also note that `foo(Base*)` doesn't need to know about `Derived` for
> it to be used with a `Derived` instance, and similarly, we would like for
> `foo(any *)` to be able to handle an `any` that contains a `Derived`
> instance while knowing only about `Base`.
>
> In other words, my argument is that `any_cast<Base>(any *)` should be on
> par with `static_cast<Base*>(Derived *)`.

I understand. I just don't agree that this is a justified use-case.

> For the record, I don't believe that this justifies changes to `type_info`
> and I wouldn't argue in support of such changes.

And yet, I think the necessary information is already there, for this
particular use-case.

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