--On Tuesday, September 09, 2003 6:43 PM -0300 Fernando Cacciola 
<fernando_cacciola@[...].com>  wrote:

>  Hi boosters,
> 
>  Following the suggestions that had been made since Optional's
>  acceptance I've updated the library.
>  I will upload the new version on main CVS tomorrow noon unless
>  someone objects.

Thanks a lot for updating optional! The new version really simplifies 
my optional usage to the point where I'm willing to commit to it in my 
current project.

I have a little bit of additional feedback. I hesitated a little bit 
before posting to the main list for fear of starting another 
should-it-be-a-pointer thread, but I hope we can avoid traveling down 
that thread again. As I mentioned earlier, one of my use cases is to 
use optional together with graph and iterator_adaptor 1.30.x. Here are 
a few things that I've noticed:

   * Tie works nicely now. That is I can now happily write:

using namespace boost; // for e-mail conciseness only

optional<graph_traits::out_edge_descriptor<XMLGraph> ::
    out_edge_iterator  out_i, out_end;
//...
tie(out_i, out_end) = out_edges(vertex, graph);


   * The out_edge_iterator is implemented as an iterator_adaptor with 
a Base = optional<edge_descriptor> . With the changes to optional I can 
now enjoy transparent construction of my out_edge_iterator's:

out_edge_iterator i(someEdge);
// instead of i(optional<out_edge_iterator> (someEdge));

This is rather convenient. It is a little bit less convenient to 
construct the end out_edge_iterator. In my case end is represented by 
an iterator with uninitialized optional state. Here I apparently have 
to write:

out_edge_iterator i(optional<out_edge_iterator> ());
//longer in its fully qualified glory

I imagine that it could be useful to have something like a universal 
'none' object that could be passed to functions expecting optionals. I 
would expect its effect to be the same as passing the anonymously 
constructed optional in the line of code directly above. That is I 
would like to write:

out_edge_iterator end(none); //optional::none?

You could think of it as analogous to NULL for pointer types (but lets 
not talk about pointers).

   * Safe optional<bool> 's as tri-bools would be quite useful to me. I 
personally would sacrifice the convenience of testing without using 
is_initialized() to gain tri-bools but I don't want to cover old 
territory. Perhaps there's some other way of making optional<bool> 's 
safer to use. What would you think of, say, using enable_if (or better 
disable_if) to disable implicit bool conversion and operator! for when 
T == bool (or when T already is_convertible to bool)?

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