[boost] Re: Re: [optional] update

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-17 15:03:11

Mat Marcus <mmarcus-boost_at_[hidden]> wrote in message
news:327066586.1063793997_at_aleph.sea.adobe.com...
>
>
> --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.
>
OK.
I can think of a use case I find very useful myself:

void foo ( int a, optional<my_really_longnamed_favority_user_defined_type> const& opt ) ;

void bar()
{
  foo(1,none);

  // as opposed to
  foo(1, optional<my_really_longnamed_favority_user_defined_type>() ) ;

}

Also, this looks like the next naturally step of the interface shift.
Now you can do:

optional<int> opt ;
opt = 3 ;

which would deprecate:

opt.reset(3);

thus, it makes sense to me to also be able to do:

opt = boost::none ;

which would deprecate:

opt.reset();

There are just a few small issues worth discussing:

(1) name: how about 'nothing', as in Haskell's Maybe "Nothing" (I prefer 'none' though)
(2) namespace: 'boost::_unnamed_ns_'?
(3) header: utility/none.hpp?
(4) interoperability: given that 'none' will be used by optional<> but won't
be totally tied to it, are there other uses for such a thing that should
be considered?

> >>
> >>    * 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 !!.

For someone maintaining code, the least of the problems is to learn simple
idioms such as !!.
I guess it would take just a few minutes to figure out what !! is all about.

> Or when the !! is inadvertently left out. I'd prefer
> compiler support against such cases.

Such support implies making optional<bool> a special case,
and this is by itself subtle.
I was initially against safe-bool for this very reason,
but with it in the interface, there are unavoidable subteltlies either way.
(with or without special support for optional<bool>)

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

Fernando Cacciola