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

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-08-27 10:27:12

Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
> Joel de Guzman <djowel_at_[hidden]> wrote in message
> news:006e01c36c6f$781de2a0$0100a8c0_at_godzilla...
>> << pardon me if this gets re-posted >>
>> 
>> Hi,
>> 
>> Is there a reason why we can't allow:
>> 
>>     optional<int&> opt;
>> 
> Short answer:
> 
> References are not objects; i.e., you can't really have a reference _stored_
> somewhere (even though most implementation do it behind the scenes)

So what? 

> optional<T> contains a copy of a value of type T, that is, an _object_ of
> type T. 
> You can't store an object which is a reference, you can only store the
> referee or a pointer to it.

So how do you state that in tuple's terms? IMO, it's the same. But you're
premise seems to be flawed. What is a tuple? Is it a heterogeneous
container of *only* "objects"?

> (see below for the long answer)
> 
>> Also, is there a reason why we can't allow:
>> 
>>     variant<int&, double&> var;
>> 
>> IIUC, internally, it's just a matter of storing a boost.reference_wrapper
>> if T is a reference.
>> 
> reference_wrapper is simply storing the address of the referee.
> optional<T&> _could_ be made to store a T*, that is, a pointer
> to the referee, but in that case, the reference itself wouldn't
> be optional... the referee would.
> Now, if optional<T&> would be really a T* in disguise,
> why would you need the optional wrapper when a NULL T* would convey
> just the same (specially given that optional<> has
> a pointer-like interface).

Why? Because of genericity. Why treat references differently? There are 
cases where you have no control of the type of T and so you have to make 
it a special case. It's like returning void. Without it, it's a real pain with
template programming to treat the special case. So what if void is *not*
an object? 

> A reference adds a level of indirection to an _existing_ objects, so,
> while you can have or not a reference, you can't have a reference
> to an object that might or might not exist.
> This is unlike pointers were the null pointer value is specially
> given the semantic of 'pointing to nothing'.
> 
> If optional<T&> were allowed, it would have to have exactly the same
> value semantics as optional<T*>, except that an additional
> addressof/dereference would be automatically added.
> 
>> In as much as tuple<int&> is allowed, I see no reason why optional
>> and variant can't allow references.
>> 
> With a tuple<> the situation is different because tuple<T&> is just
> a class with a reference data member, and the language specifically allow

That's obvious. However, that's an implementation issue. I am more
concerned about the concepts. IMO, tuples, optional and variant should
share the same underlying concepts as regards to the types they can
operate on. Tuples is a precedent. I'm glad it supports references. I
believe optional and variant should follow. Conceptually:

    tuples: a container of heterogeneous types
    variant: a union of heterogeneous types
    optional: a variant<T, nil>

> data members to be references but by means of special rules.
> Since references are not objects, when you have a reference data member
> you're not necessarily adding the data member to the class storage
> (even though most implementations do just that).

Again, implementation detail. Let's not dwell on that. Let's focus on the
concepts. For that matter, pardon me if I snip the rest of your explanations
regarding more implementation issues.

[snip]

> IOWs, optional<T&> be have to represent an explicit special case.
> Thus, is there any real-world reason you need optional<T&>?
> At least you can always use reference_wrapper explicitely, as in
> optional< reference_wrapper<T> >.

Yes, I have a use-case. But again, I wouldn't want to digress. As I said,
I wish that we focus only on the concepts.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net