2013/12/7 TONGARI J <tongari95@gmail.com>
2013/12/7 Antony Polukhin <antoshkka@gmail.com>
2013/12/7 TONGARI J <tongari95@gmail.com> <...>
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,