Re: [boost] Re: Re: Optional, tie, and iterator_adaptor

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-09-01 13:47:21

--On Monday, September 01, 2003 2:57 PM -0300 Fernando Cacciola 
<fernando_cacciola_at_[hidden]> wrote:

> Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message

[snip]

>> After reading the documentation more carefully I learned that
>> optional models pointer behavior. I spelled out how the code might
>> look:
>>
>>  boost::tie(*begin, *end); file://sorry, ASSERT && looks too strange
>>
>> Wow, that looked strange to me. I don't think of begin and end as
>> pointers at all here.
>>
> Right, they're not pointers and you shouldn't see them as such.
>
> I think that your report is very important because it shows me
> that while one may expect the need for special constructs in order
> to 'access' an optional value, such need isn't there when one
> wants to initialize or assign an optional.
> It was very reasonable to expect optional<> to work with tie as
> that is just assignment and assignment is always defined.

Yes, it seems like optional is just the sum (disjoint union) of nil 
and T, so why not allow implicit construction and assignment from T. 
Of course, I realize that there may be technical obstacles to getting 
optional to work transparently with tie in this way(doesn't tie 
normally create a tuple of references?).

[snip]

> I think that OptionalPointee's documentation failed its purpose.
> That concept is intended to be exactly what you proposed,
> except that I left initialization/assignment aside.
>
> The concept just explains that the operator * and -> syntax
> is used to access the a value that is possibly uninitialized,
> WITHOUT implying that a model of this concept IS a pointer.
> The concept was invented precisely to allow the same
> syntax to be used with entities that are NOT pointers.
>
> The particular choice of operators is to allow pointers to be
> models of the concept.
>
> Perhaps it is the name which is misleading. It can be renamed as
> PossiblyUninitialized if that helps.

OptionalPointee is a bit misleading for me. Also I work in a group 
that is ultimately responsible for transferring our technology to the 
product teams, so I need to be able be convince others that my code 
will be maintainable. I will probably choose to avoid the pointer-like 
operator interface since I think it makes optional harder to 
use/explain. I'm not sure that PossiblyUninitialized is the best name 
for the concept, but it works a bit better for me since it's more 
about Optional and less about (the arguably distracting) Pointee.

> And it should incorporate initialization and assignment.

[snip]

Great. This should definitely help with my use cases. I'm still 
curious whether there will be a recipe to use optional with tie. And 
if there is such a recipe I wonder whether pointer will still be a 
model of the Concept.

 - Mat

P.S. Doesn't ML have offer an option type? Haven't had a chance to 
look into this yet.