C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::get_if for std::any

From: Henning Meyer <hmeyer.eu_at_[hidden]>
Date: Sat, 12 Apr 2025 22:09:58 +0200
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.

On 12.04.25 19:51, Ville Voutilainen wrote:
> On Sat, 12 Apr 2025 at 20:31, Henning Meyer via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>> Is there a reason, why there isn't or shouldn't be
>> std::get_if<T>(std::any*)?
>>
>> I believe both are based on boost designs, and boost::variant did not
>> have a get_if.
>>
>> I would like to work generically with std::variant and std::any.
> So, write a simple utility to do that: https://godbolt.org/z/exM897Gjd
>
> As far as adding a std::get_if that can take an any* goes, fine by me,
> I wouldn't be opposed to it, it seems reasonable. Considering the
> simplicity
> of just doing it yourself, I don't see myself writing a proposal for that.

Received on 2025-04-12 20:10:04