Re: [boost] [variant] Why boost::get<Base>(derived) not supported?

Subject: Re: [boost] [variant] Why boost::get<Base>(derived) not supported?
From: TONGARI J (tongari95_at_[hidden])
Date: 2013-12-07 11:21:18

2013/12/7 TONGARI J <tongari95_at_[hidden]>

> 2013/12/7 Antony Polukhin <antoshkka_at_[hidden]>
>
>> 2013/12/7 TONGARI J <tongari95_at_[hidden]>
>> <...>
>>
>> > Maybe we can promote this idea to something more general, like
>> > 'variant_cast', not necessary have to be in base-derived relationship
>> but
>> > just something convertible.
>> >
>> > Does that make sense?
>> >
>>
>> I'd prefer not mixing functionalities. We can make polymorphic_get<> work
>> only for polymorphic casts (Base and Derived can be checked using type
>> trait).
>>
>
> I just looked into the code of get, and it also uses visitor, a bit
> disappointed.
> Since the current boost::get requires exact type match (except const),
> there's only one viable way from the types, I thought it might do better
> under the hood (i.e. single if-check instead of switch), but it didn't,
> it's just a more restrictive visitor than what I shown in my sample code.
>
> And for type-checking, I think the user should use .which(), but I don't
> know how many ones already did that with get, so it's a valid concern not
> to break others' code...otherwise I'm inclined to make it the default
> behavior of boost::get.
>
> I'm OK with polymorphic_get (except the long name, though), since that's
> my use-case.
> But variant_cast seems more attractive.
> You can do variant_cast<Base&>(derived) or variant_cast<Base*>(&derived)
> in that case, and variant_cast<Compatible>(v) for other conversion.
> If you want to go further, you can ensure that at least one viable
> conversion exists at compile time by some metaprogramming tricks.
>

Aside: Do we have something like unconditional_get that doesn't perform the
runtime check?
Sometimes the type-safety can be ensured by my program logic.

Thanks,