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

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-01 13:37:17

Joel de Guzman <djowel_at_[hidden]> wrote in message
news:010201c37027$157b8d80$64646464_at_godzilla...
> Brian McNamara <lorgon_at_[hidden]> wrote:
> > So I completely disagree that optionals should mix the interfaces of
> > optional and the wrapped object into one.  I think there should be an
> > explicit unwrapping operation.  But this is just my opinion, based on no
> > practical evidence/experience, and I'm sure there are trade-offs either
> > way.  I'll explain the crux of my own reasoning below.
>
> One can think of an optional<T> as conceptually a specialized but
> nevertheless, *IS-A* T,  with the added specialization that it can
> be in a dead-uninitialized state. Maybe we'll call it a zombie object,
> undead object, you name it ;-)
>
Theoretically, yes.
But there are practical barries here.

Unfortunately, in C++ subclassing is the only subtying mechanism,
but you can't subclass a non class type, so you can't subtype
an arbitrary T.
IOWs, there is no way to completely implement an optional<T> which
*IS A* T.

The closer we could get is to have an implicit ctor and and implicit
conversion to T, but that would only take us half the way, so there
is little practical sense in approaching the problem this way.

> > On Sun, Aug 31, 2003 at 11:59:42PM +0800, Joel de Guzman wrote:
> >> It's really strange (and hard to explain) that you have to dereference
> >> optional<B>. Example:
> >>
> >>     F(tuple<A, optional<B>, C> args)
> >>     {
> >>         A a = get<1>(args);
> >>         B b = *get<2>(args); // strange!
> >>         C c = get<3>(args);
> >>     }
> >
> > I don't think it's strange at all; an optional<B> is not a B!
>
> Even if I agree with you that an optional<T> should not be a T,
> an optional<T> is definitely not a pointer to T.
>
Definitely!
If HTML had blinking banners I think I'd use one to state this :-)

Yet iterators are not pointers either but they do use
operators * and ->

>
> > As another example, FC++ lists support conversion-to-bool as a test for
> > NIL:
> >    fcpp::list<int> l = NIL;
> >    if( l )                  // if l not empty
> >       cout << head(l);      // print first element
> > Clearly if 'l' were an optional, the "if" test would have a different
> > meaning.  I know you've been supporting a separate way to do the test
> > (with "==none"), but I think that's completely arbitrary.  The two
> > issues are both really the same issue, in my mind.
> >
> >
> >> Of all the types involved in the passing of arguments to the semantic
> >> actions, the optional doesn't fit nicely because it is the only one
> >> that has mixed value/pointer semantics. I am tempted to not use
> >> optional<T> because of this and instead use variant<T, none>,
> >> but I hate to miss the performance advantage of optional vs.
> >> variant<T, none>.
> >
> > I have not used variant and know little about it, but I imagine you have
> > to explicitly tell a variant "which type" you expect to get out of it.
> > I think the same is true of optional; the call to operator*() (or
> > whatever) says "I want the T type" (rather than the 'none').
>
> Right. In fact, looking at it more closely, I *could* almost agree with you
> that an optional<T> is not a T. There is in fact a getter function (get).
> In fact all three (tuple, optional and variant) have a get function. That's
> fine, yet, here again, the optional does not jive well because it returns
> access *by pointer* whereas both tuple and variant return access by
> reference.
>
This get() issue we agree should be fixed.

Fernando Cacciola