Re: [boost] Re: [boost.optional && boost.variant] Why can't we allowreferences?

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-08-28 09:53:29

Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:

> I'm way overprotective, I guess
> (maybe it's because I'll be father for the first time
> in a couple of months :-)

Congratulations!

> The only remaining issue is the optional<> interface:
> 
> Currenty, there is the following:
> 
> optional<T>::optional ( T const& ) ;
> optional<T>::reset ( T const& ) ;
> 
> But If 'T' is allowed to be a reference, then these should have to be
> changed to:
> 
> optional<T>::optional ( T ) ;
> optional<T>::reset ( T ) ;

I think reset should be:

    optional<T>::reset ( T const& ) ;

Following reference assign semantics, an optional reference once bound
cannot re-bind to another reference. So, we can be able to:

    int i;
    optional<int&> opt(i);
    opt.reset(3); // same as i = 3

Which is similar to:

    int i;
    int& r = i;
    r = 3; // same as i = 3

I think this is a big difference of semantics to T*. We can only bind 
an optional reference at construction time. This is an advantage to
a plain T* because we are assured that no rebinding will take place.
Thus, I have to disagree that we would never explicitly use optional<T&>.
I think there's merit in its usage too.

> the question is, what should be the 'conceptual' signature
> of these functions? (how should they be documented).
> 
> The same goes for operator*().
> 
> For non-reference types, it is: T& operator*();
> but for reference types, is has to be: T operator*();
> 
> Anyway, this issues are the same for tuples, so whatever it was
> done there it can be done with optional<>.

How about:

    typedef typename call_traits<T>::param_type ctor_param; 
    typedef typename call_traits<T>::param_type assign_param;
    typedef typename call_traits<T>::reference return_type;

    optional<T>::optional(ctor_param arg);
    optional<T>::reset(assign_param arg);
    return_type operator*();

I think that's pretty good documentation in and by itself. It might also be
a good idea to make the return type part of the public API. Sometimes, 
we want to have temporaries, e.g. to circumvent the function forwarding 
problem. Example:

    optional<T>::return_type v = *opt;
    a_func_accepting_a_reference(v);

Many thanks!
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net