Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 10:52:09

----- Original Message -----
From: "William E. Kempf" <wekempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, December 12, 2002 12:18 PM
Subject: Re: [boost] Formal review: Optional library

> Fernando Cacciola said:
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> >> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> >> > Perhaps this could be called get_pointer() as shared_ptr<> does.
> >>
> >> get_pointer() would be... less objectionable. :-)
> >>
> > This particular free function is precisely intended to decouple this
> > functionality (get a pointer that points to the value) from the class
> > type (optional<> in this case); so it makes sense to be a commonly named
> > free function.
> > But then, get_pointer() is the common name, so it has to be that one.
>
>
> >> bool operator==(optional const & a, optional const & b)
> >> {
> >>     if(a.initialized() != b.initialized()) return false;
> >>     return a.initialized()? *a == *b: true;
> >> }
> >>
> >> That is, an unitialized optional is equal to an unitialized optional,
> >> and not equal to an initialized one.
> >>
> >> Two initialized optionals are equal when their values compare equal.
> >>
> >> If you think of an optional as a constrained std::vector<T>, you'll
> >> see
> > that
> >> the above semantics correspond to vector<>::operator==.
> >>
> >> The other way of thinking about an optional<T> is that it is capable
> >> of storing all possible values of type T plus an additional value
> > corresponding
> >> to the uninitialized state. In other words, optional<int> can be
> >> thought
> > of
> >> as an integer that can store INT_MIN...INT_MAX+1, with INT_MAX+1 being
> >> interpreted as uninitialized. The above comparison does the right
> >> thing
> > for
> >> this model, too.
> >>
> >> A variant<T, nil_t> would have the same operator==, too.
> >>
> > Well, this is exactly what William suggested.
> > Still I don't like it.
> > But thanks to William insistance on a sound rationale, I realize now
> > that the real problem
> > is not the personally-odd definition that something is definitely not
> > equal to nothing
> > (instead of undefined); since this definition doesn't look odd to many
> > of you,
> > but the fact that such definition would look ackward with respect to the
> > pointer-like interface.
> >
> > Anyway, as I posted recently, I'm just about to conclude that relational
> > operators
> > could be properly defined as a synonim for: get_pointer(o1) .relop.
> > get_pointer(o2).
> > I found this definition totally consistent with pointer semantics and
> > the implied
> > aliasings.
>
> So, from recent postings it sounds like you've made several more decisions
> on the interface (deep const, relational ops, get_pointer(), explicit
> templated constructor from other optional<> types, anything else?).  Can
> we get you to illustrate the changes and/or republish the documentation
> again?  I think we're finally at a point that everything I brought up has
> been addressed to my satisfaction, but before I drop out of the discussion
> I want to make sure :).
>
Yes. I'm precisely doing it. I'll republish everything ASAP... stay tuned.

Fernando Cacciola