Re: [boost] Re: Optional, tie, and iterator_adaptor

From: Mat Marcus (mmarcus_at_[hidden])
Date: 2003-08-29 14:23:08

--On Friday, August 29, 2003 2:56 PM -0400 David Abrahams 
<dave_at_[hidden]> wrote:

> Mat Marcus <mmarcus-boost_at_[hidden]> writes:
>
>> ### Question 2
>>
>> In another case I am trying to use optional with iterator_adaptor
>> (1.30.x version).
>
> Whoa; don't do that ;->
> It'll hurt (comparitively speaking).
>
>> 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.
>
> What do you mean by "the signature of the... class"?

Sorry: meant to say "... of the eventual iterator class's constructor"
>
>> 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.
>
> No, you want the ability to add your own constructor to adapted
> iterators.  You need control over the library components *you*
> design, and and are trying to remedy that by influencing the design
> of optional.  Unfortunately you came to the wrong iterator_adaptor.
> Please see the CVS one ;-)

I mentioned iterator_adaptor 1.30.x as an example of a case where "the 
obvious workaround" is not possible. But even where I could add 
"convenience" constructors I'm still asking whether an optional-like 
class that offered an implicit constructor (and also worked with tie) 
might not be useful.
>
>> 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.
>
> Well, that's a slightly different issue and you may be right.  On the
> other hand, you can always define a type which implements those
> implicit constructors:
>
> template <class T>
> struct implicit_optional : optional<T>
> {
>    implicit_optional() {}
>    implicit_optional(optional<T> const& x) : optional<T>(x) {}
>    implicit_optional(T const& x) : optional<T>(x) {}
> };
>
> You could use that in your interfaces.

And then slice it back to option internally to avoid bool weirdness? 
Might work out. Got any good ideas to help use optional with tie?

>
>> Sorry if this has already been covered, but here my question is:
>> Have you experimented with a variant of optional that drops the
>                                ^^^^^^^^^^^^^^^^^^^
> Whoa; you're making me dizzy with discriminated union-ness!

Hehe.

>
>> 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?

Still curious about this as the temptation remains to explore a 
different part of the design space...

 - Mat