----- Original Message ----- From: "Joel de Guzman" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, December 11, 2002 5:18 PM Subject: Re: [boost] Formal review: Optional library
> ----- Original Message ----- > From: "Fernando Cacciola" <[EMAIL PROTECTED]> > > > > > It's trivial to make that a free function like get. Or further, to make > > > a subset API for optional. > > > > > You can certainly do the same with variant. The point is that with > > optional<> it is *easier*. > > With optional<> you don't need to specify the type of the wrapped value all > > the time as with variant; and you don't need to explicitly test if the > > variant holds a "nil_t" in order to see if it is initialized. > > And my point, again, is that you can easily add an *easier* API > that does exactly like your optional API *over* the variant. My > concern is primarily about redundancy of code. I don't see any > reason why the optional and the variant can't share the same > underlying infrastructure. > Aha! You just meant that optional<>, with a given interface, could be implemented on top of variant_t<T,nil_t>? Yes, definitely. In fact, if optional<> is accepted, when we have variant<>, it is quite likely that I do just that. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
