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

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 
comparison.
'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.

Best

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com/