[boost] Re: Re: Re: Re: Formal review or Variant Library (Ed B.)

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-19 14:25:20

"David Abrahams" <dave_at_[hidden]> wrote in message
news:un0ks86bl.fsf_at_boost-consulting.com...
> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
>
> > "David Abrahams" <dave_at_[hidden]> wrote in message
> > news:usmuk890r.fsf_at_boost-consulting.com...
> >> "Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> >>
> >> >  Any idea about what to do with reference to reference problem?
> >>
> >> What's the problem?
> >>
> > Currently, optional<Y> has:
> >
> >     explicit optional ( T const& val )
> >     T*       get();
> >     T*       operator->() ;
> >     T&       operator *();
> >
> > those are all illegal if T is a reference type.
>
>     explicit optional ( typename add_reference<typename
add_const<T>::type>::type val )
>     typename add_pointer<typename remove_reference<T>::type>::type
get();
>     typename add_pointer<typename remove_reference<T>::type>::type
operator->() ;
>     typename add_reference<T>::type       operator *();
>
I see.
Correct me if I'm wrong:

You're essentially saying that, for instance, optional<> is initialized with
a "value of type T";
and that whether that is expressed with 'T' or 'T const&' is an
implementation detail.
It implies that the user should not assume that the initializer is not taken
by-value.

Similarly, operator*() returns 'the value', being an implementation detail
whether this is 'T' or 'T const&'.

Well, this sounds good by itslef.

Still, there are other problems with optional<T&>:

AFAICT, one way or another, the 'value' that optional holds, in this case of
reference type,
must be stored in the aligned storage.
But you can't get a pointer to a reference so you can't have somehing like:

new (storage) U(value) ; where U=T&

IOWs, you can't have a real 'copy' of a reference with storage and all
(if you could, you could also have a pointer/reference to it).
References are not required to be actual objects, they don't need to be
stored anywhere.

You can have a pointer to the referenced object, but then, the optional<T&>
would not be
an 'optional reference' object but a reference to an 'optional object', so
we're back to argument
that in this case you can use a pointer instead of optional<>.

...
Now that I think about it, optional<T&> doesn't make sense because T& is not
a object, and
optional<U> represent an optional U object.
References are not objects.
IOWs, that you have or don't have a 'U' means that if you have an U you have
it stored somewhere.

> >> >
> >> > What was the idea of:  optional< exactly<T&> > ?
> >>
> >> It's an ambiguity breaker: a way of specifying, when constructed with
> >> a variant<T,T&>, that you want to get the T& and not the T.
> >>
> > hmmm, shouldn't 'exactly' appear along with extract then?
> > What's the meaning of "optional< exactly<T&> > " by itself, without
> > variant<T,T&> in the scene?
>
> I dunno, maybe nothing; we were talking about optional as a
> replacement for extract.
>
Aha, OK.

--
Fernando Cacciola