Mat Marcus <mmarcus-boost@[...].org>  wrote in message
news:327066586.1063793997@[...]..
> 
> 
>  --On Wednesday, September 17, 2003 1:05 PM -0300 Fernando Cacciola
>  <fernando_cacciola@[...].com> wrote:
> 
>  [snip]
> 
>  > Mat Marcus <mmarcus-boost@[...].org> wrote in message
>  > news:318546735.1063785477@[...]..
>  >> 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




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