Re: [boost] Report from Mont Tremblant C++ Committee meeting

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-11 18:53:10

Hi Joel,

>> cannot but to bind 'opt' to 'ref' if 'opt' happens to be absent,
>> then IMO it just better do that _always_, no matter if 'opt' is
>> absent or not.
>> The other choice of semantic would be inconsistent and depending on
>> the previous state of 'opt'.
>
> Again, my main objection is this rebinding thing. I don't care so
> much about the "pointer interface". It's easy to simply ignore it.
> My main problem is with this rebinding thing. It's counter intuitive
> and does not follow the tuple<T&>

Which it can't since a tuple<T&> couldn't be referencing nothing.

> NOR the variant<T&, nil> sementics.

OK, this is much better analogy.

> In Spirit-2, I will be needing all three as part of client interface
> of semantic actions:
>
>     a >> b    --> tuple<A, B>
>     a | b     --> variant<A, B>
>     !a        --> optional<A>
>
> It just so happens that !a is a synonym for:
>
>     a | eps   --> variant<A, nil>  !!! DANG !!!
>
> !a and a | eps behave differently!!!

I don't know what 'eps' is for so I can't follow the equivalence between 
"!a" and "a|eps"

Nevertheless, I can see that if optional<A> MUST be equivalent to 
variant<A,nil>; _and_ variant<T&,nil> doesn't rebind, then neither should 
optional<T&>.
But to complete the argument we would need to show that
(1) optional<A> MUST be equivalent to variant<A,nil>
(2) variant<T&,nil> doens't rebind when its current type is T&, while it 
clearly binds when is nil.

(2) is easy since variant<> just wouldn't do anything special, so it just 
wouldn't rebind.

But (1), I'm not sure... How can we _argue_ that it must (or must not) 
without specific use cases or moral positions?

Specifically... wouldn't you find odd that the result of assignment depends 
on whether the lvalue was previously absent or not? Don't you agree that 
_most_ people would call _that_ counterintuitive?

In the end, one can always resort to variant<A,nil> if that and _exactly_ 
that is needed.. why should optional<A> be nothing but a thin interface on 
top of it?

The basic fact that 'true' references don't rebind on assignment is because 
a C++ reference is _intended_ to be really just an alias for an object; but 
then you can't have an absent alias for an object can you? so we would have 
to begin again discussing the nature of an optional reference. And once we 
do, we discover that an optional reference is really just a "lexically more 
convenient" pointer.

In most languages I know of which have any form of "nullable" type, 
"references" are really equivalent to C++ pointers, and there assignment 
does rebind.  Take .NET nullable<T> for example.

> My opinion is very strong on this. THIS BEHAVIOR IS WRONG!

Only if (1) holds.
Can you show with a solid argument that (1) _shall_ hold?

Best

Fernando Cacciola