[boost] Optional, tie, and iterator_adaptor

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-08-29 13:18:07

I'm finally getting around to playing with optional. A couple of 
questions.

### Question 1

One of the projects that I am working on makes heavy use of 
tuples/pairs and as a result tie. It appears that some of the code may 
be improved by the use of optional. It is not clear to me whether I 
can make it work with tie. Here's a pseudo-example:

// Assume foo and bar are classes *without* default constructors
  std::Pair<Foo, Bar> do_stuff();
  boost::optional<Foo> foo;
  boost::optional<Bar> bar;

It seems that if I want to use tie here I would have to do something 
like:
   boost::tie(*foo, *bar);

Of course for real pointers this would be akin to a null dereference 
and so I expect that boost::optional would assert here. So my question 
is: Is there and idiomatic way of using optional and tie together in 
situations like this?

### Question 2

In another case I am trying to use optional with iterator_adaptor 
(1.30.x version). Here I would like the "base" for my iterator_adaptor 
to be, say, boost::optional<Baz>. The value_type is to be Baz. But 
iterator_adaptor chooses the signature of the eventual iterator class 
for me. As a result, clients of my iterator have to pass 
::boost::optional<Baz>'s to the constructor. But I would also like 
them to be able to pass plain Baz's. That is, I want a non-explicit 
constructor for optional. In this case I don't have the freedom to 
create another constructor to easily workaround this problem. Reading 
back over the formal review threads for optional, I noticed that the 
reason for the explicit constructor was to support the pointer-like 
nature of optional. Right now I am questioning whether the 
pointer-like semantics is worth it to me. I would probably prefer that 
clients type more to test whether a value is initialized so that they 
can type less to call a function that takes an optional as a parameter 
when they have a value to pass in. Sorry if this has already been 
covered, but here my question is: Have you experimented with a variant 
of optional that drops the pointer-like semantics, allowing implicit 
construction and disallowing implicit safe-bool conversion, and if so 
what did you learn that made you favor the current set of tradeoffs?

Thanks,
Mat