Re: [boost] Formal review: Optional library

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-12 10:18:46

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 :).

William E. Kempf