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

[Mat Marcus]

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

Mat Marcus <[EMAIL PROTECTED]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost