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

From: Mat Marcus (mmarcus-boost_at_[hidden])
Date: 2003-08-29 16:00:30

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

> Mat Marcus <mmarcus_at_[hidden]> writes:
>
>>> 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?
>
> I didn't have that in mind, no.  Why slice when you can avoid a copy
> instead?  and what is "bool weirdness"

I meant something like this. It seems that optional takes some pains 
to mimic pointer semantics. In particular testing whether an optional 
== 0 is suppose to be equivalent to calling initialized(). Implicit 
constructability seems in conflict with this idiom, so I was thinking 
it might be a good idea to avoid using something like 
implicit_optional except in interfaces. But it seems kind of painful 
to bend optional in this direction. Perhaps I will just try creating a 
new class, borrow some implementation techniques from optional.

>
>> Might work out. Got any good ideas to help use optional with tie?
>
> Seems to me you could use a similar shim, as long as it had a const
> assignment operator:
>
>            tie(shim(foo), shim(bar)) = ... ;
>
> Not very generic, but it should work out.
>

Interesting. Just thinking out loud so maybe I'm off in space, but 
maybe something like

   tie_optional(foo, bar) = ... ;

could create a tuple of appropriate shims. Of course then I would 
really rather spell such a tie_optional as tie <g>.

 - Mat