--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

Reply via email to