Re: [boost] Re: [optional] update

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-09-17 12:19:57

--On Wednesday, September 17, 2003 1:05 PM -0300 Fernando Cacciola 
<fernando_cacciola_at_[hidden]> wrote:

[snip]

> Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message
> news:318546735.1063785477_at_aleph.sea.adobe.com...
>> 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); file://optional::none?
>>
> Well, something like this can be done, though I wonder why couldn't
> you just use the default constructor as in:
>
> out_edge_iterator end;
>
> which is the cannonical way to introduce an uninitialized optional<>.

Sorry, my example was ill chosen. Let me try again. I am actually 
trying to simplify the implementation of out_edges whose signature 
(leaving out some qualifications) happens to be:

  std::pair<out_edge_iterator, out_edge_iterator>
  out_edges(vertex_descriptor);

At the end of my out_edges implementation I must return a pair of my 
iterator_adaptor based iterators that I will ask you to recall have a 
Base of optional<edge_descriptor>. So my code looks something like:

  return std::pair<out_edge_iterator, out_edge_iterator>(
    calculated_begin, optional<out_edge_iterator>());

I was wishing to be able to replace the second parameter with, say, 
none. In general I suggest that functions that accept optional 
parameters should be as easy to use. I think that the new version of 
optional makes it very easy to pass such functions a T, but it remains 
slightly awkward to supply a parameter of none. I could probably think 
of other uses for 'none', perhaps "== none" as an alternative to 
is_initialized(), but that's another question.

>>
>>    * 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)?
>>
> I decided not to treat optional<bool> specially since as Doug just
> said there is boost::tribool.
> In order to use optional "safely" and uniformly in the presence of
> [T=possibly bool] all you have to do is not to use the safe_bool
> feature. For instance, you can consistently use the double-bang
> idiom:
>
> if ( !!opt ) ....

Sure, there are safe idioms to follow. What concerns me is when, say, 
some comes to maintain a piece of code and is not familiar with idioms 
such as !!. Or when the !! is inadvertently left out. I'd prefer 
compiler support against such cases. But I understand your rationale. 
I suppose I could use optional_base, implicit construction, assignment 
from T and a constructor from 'none' to get exactly what I want.

Thanks again for your recent set of changes.

 - Mat