Boost logo

Boost :

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
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?


Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at