Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-11 15:50:45

----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, December 11, 2002 5:18 PM
Subject: Re: [boost] Formal review: Optional library

> ----- Original Message -----
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>
>
> > > 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