Re: [boost] Formal review: Optional library

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-12 13:45:33

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

> ----- Original Message -----
> From: "Peter Dimov" <pdimov_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Sent: Thursday, December 12, 2002 1:00 PM
> Subject: Re: [boost] Formal review: Optional library
>
>
>> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>> > > Yes, I thought about that, too. But if the current swap semantics are
>> > > retained, it should simply be removed. Otherwise optional<T>::swap
> must
>> > > offer at least swap(T&, T&)'s guarantee.
>> > >
>> > I'm not sure I follow.
>> > What are swap(T&, T&) guarantees in general?
>> > I thought this depended on the specific type.
>>
>> True, swap()'s guarantees depend on the type. If T provides a
>> nothrow/strong/basic swap, optional<T>::swap should be at least
>> nothrow/strong/basic, respectively. I think that this can be done provided
>> that T(T const &) is strong and T::~T is nothrow.
>>
> I still have to tink about this ...
>
>> > 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.
>>
>> Optional does not have pointer semantics.
>>
> Not _entirely_, sure; but I think it can be accurately said
> that it has _partly_ pointer semantics, which is reflected
> by its pointer-like interface, and _partly_ value semantics,
> which is reflected by its container-like interface.
>
> Precisely because its dual nature can be confusing,
> it is very important that boths parts of the interface,
> which reflect different semantics, can be unambiguously
> differentiated so the actual semantic can be inferred
> without doubts.
>
> In order to achieve this, I considered fundamental the following
> rule of thumb:
> If optional<> is replaced by a pointer, and provided that uninitialized
> optionals are defined as null pointers, any exression using optionals
> should either fail to compile or behave exactly the same.
> This rule allows the programmer to unambiguously infer the
> semantic of a given expression using optional.

Have you got even a single real use-case where an optional can be
usefully substituted for a pointer in generic code?

I think it's important to have a few of these in hand before
predicating interface design principles on the idea.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution