From: Itay (itay_maman_at_[hidden])
Date: 2002-06-30 14:23:20
"Douglas Gregor" <gregod_at_[hidden]> wrote in message
> On Saturday 29 June 2002 03:26 pm, Itay Maman wrote:
> > >I'm happy with that. Personally, I would strongly
> > >discourage the use of variant_cast anyway because it
> > >is the only mechanism to access a variant that is
> > >not guaranteed to succeed at run-time. Visitors are
> > >typesafe as would be a switch-on-type construct.
> > (Following this line) Then, what do you think about
> > getting rid of variant_cast? This, obviously,
> > contradicts the "variant with an any-like interface"
> > feature, but it might have one major positive effect:
> > It requires any-based code to be rewritten in a safer
> > manner.
> If boost::any didn't exist I might agree. But boost::any has been around
> quite a while and there has been no alternative variant type in Boost. I'm
> afraid that there are many users using boost::any as the variant type now
> progress. Would the omission of variant_cast make the conversion from
> boost::any to variant too involved, such that users won't bother?
> The other question is whether there are cases where variant_cast really is
> useful. For instance, the context may dictate that only one of the types
> the variant is legal. I have come across this case a few times recently in
> own projects.
> So I guess I'm backing away from my current statement. I think that
> variant_cast is a lot like std::auto_ptr::release: it's powerful, maybe a
> little dangerous, but necessary for some cases. We should strongly
> the use of the safer access methods (visitor & typeswitch), but supply
> variant_cast for those corner cases that need it.
I like pretty much the comparison with auto_ptr::release(). However, this
brings up the following question:
Since variant's interface is practically compatible with boost::any's, why
don't we rename variant_cast to any_cast ?
This way, porting an existing code from any to variant,
will basically require the developer to change a single #include line and a
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk