Re: [boost] Formal review: Optional library

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-12-11 15:30:39

----- Original Message ----- 
From: "William E. Kempf" <wekempf_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.
> 
> To add my own 2 cents on why we should have optional<> instead of just
> relying on variant<T, nil_t> is along the same lines as Fernando is trying
> to convey here.  A std::pair<int, int> provides all the functionality
> you'd need for a "point" type in a GUI framework, but we'd still want to
> have a point type (which may be implemented in terms of std::pair<int,
> int>) in order to bring the syntax more in line with domain we're dealing
> with.  The exact same thing applies to optional and variant.
> 
> The argument about optimizing POD cases is less compelling.  Even if the
> optimization was considered necessary, I'd think you could provide it with
> the variant<POD, nil_t> as well (though it would be a trickier
> implementation).

Oh don't get me wrong. I vote to have an optional. Again, my point is 
that it should be noted that we can easily write a thin API over the 
variant that way, we will avoid redundancy of code. Yet of course,
that would have to be in the future since we do not have a variant
yet.

Joel de Guzman
joel_at_[hidden]
http://www.boost-consulting.com