On Sat, 12 Apr 2025, 21:10 Henning Meyer via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I know that I can write a wrapper to make my type erased types have a
> uniform interface in my code base. And other people have written their
> wrappers in their code bases. I am looking at this from a tooling
> perspective:
>
> How can I make a tool (a debugger or static analyzer) recognize that we
> have a type-erasing type and/or tagged union and access the contained
> object for display or checking?
>
> It works really well with containers by looking for begin() and end()
> methods or free-standing functions.
>
> The current state is that every library needs special handling in every
> tool, and most of it is missing, including standard library types.
>
> I would like it if get_if (with variant_size/variant_alternative
> specializations where applicable) were encouraged as an interface to
> any-like and variant-like types, just like std::get for tuple-likes and
> std::begin/std::end for containers
>
> The optimized implementations of std::any (and std::function) use a
> single function pointer to operate on their contained state, which makes
> them much harder to handle than e.g. the control block with embedded
> data used by std::make_shared which is typically implemented by pointing
> to an object with a vtable, which allows convenient type recovery via RTTI.
>
> I find std::get_if/std::any_cast(any*) much easier to handle than their
> throwing counterparts from a tooling perspective.
>

I don't see how get_if (or any_cast) helps for std::any because you can't
use it without knowing the type to pass as the template argument. For
variant you know the alternatives, and have an index. For std::any you
still need to look at the implementation-specific type erased data to see
which type is stored.

>