I'm not talking so much about how the changes to `any` could or should be
implemented. I wanted to discuss the potential usefulness of the proposed changes
to `any`. For the record, I don't endorse the proposed changes to `type_info` either and I think that the OP really wants the `any` changes, that's what should be proposed and discussed.
std::any type-erases the copy ctor and the dtor of the encapsulated type. It does that on assignment, and codegens that bit of the rtti needed to recover with get.
all you need is some way to get a typelist of bases and you can codegen the code, on assignment. You *already* have to do that in a compilation unit where the full definition of the stored class is available. You can ask for it in a compilation unit where only a forward-decl is available, and that's alright, you'll be going through an extern template that you generated in the other compilation unit.
It's really not difficult if you've ever done your own type-erasure.
So, basically you are proposing a table of upcast functions which is generated at compile-time at the assignment site and associated with the `any` instance. Then the cast function can look for the target type in the table and execute the upcast function. (Or a single function with a switch-case statement could be generated).
Yes, this will work. But it seems to me that these tables will duplicate information that's already available in the runtime to support dynamic_cast and can allow the cast to be implemented without changing either `type_info` or `any`.