Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-17 15:35:00

Joel de Guzman wrote:
> [SNIP]
> Agreed. After thinking about it for some while, it seems I am being
> swayed by the reference_wrapper model. If you see my other post
> regarding the swapability of optional<T&> and tuple<T&>, I seem
> to be showings signs of concession. I might, on one condition:
> Allow rebinding *ONLY* on assignment from another optional<T&>.
> int a = 1;
> int b = 2;
> optional<int&> x(a);
> optional<int&> y(b);
> x = y; // rebind
> y = a; // no rebind! assign a to b
Why should direct value assignment be different from assignment?

That is, why wouldn't

y = a ;

be any different from:

y = optional<T>(a);


> That said, I still am unsure because this will ultimately open a
> can of worms for the behavior of tuple<T&> and variant<T&, nil>.
I've been thiking about variant<T&,nil> and I concluded that it's an unfair
'nil' there is just a type, it has no special meaning and is totally
unrelated to T&.
It makes sense for variant<A,B> to follow simple rules becasue variant
itself knows nothing about A or B or their relation.
But the uninitialized state of optional is not just an additional state. It
is a special state.
In fact, having a special treatment for that special state is the whole
point about optional<>.
So to be fair, optional<A> should follow a model more like a subset of
variant<A,B,..etc...,NIL> were NIL there were a special type with a special
meaning. In that case, the transition from A/B/etc to/from NIL would not
have to be as blind and unattended as the transition from A to/from B.

I wonder if "A | Nothing" in Haskell is really just exactly like "A | B"...

> Howard Hinnant hinted at a proposal to simply fix swap for
> tuple. Maybe that's all that's needed.
> This might be my last post on this issue.

I hope it isn't.

> I care for consistency in their behavior. If you decide to fix one, then
> the others should
> be fixed.

Why? what's is wrong about them?

> do not buy the argument that optional is different
> because of its nullability property.

But it is.
I recentely posted with a sample code snippet why nullability affects the
way assignment works if no-rebinding is used.. Tuple and Variant don't show
that problem, becasue they are not nullable.

> In the recent thought
> experiments, we never touched on null optionals in any way.
Which hints that rebinding could be needed even in spite of that.
But anyway, the only reason why I think is needed is because of nullability.


Fernando Cacciola

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