RE: [boost] optional vs variant vs any

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 09:18:00

----- Original Message -----
From: Vesa Karvonen <vesa.karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 29, 2001 5:06 PM
Subject: [boost] optional vs variant vs any

> [SNIP]
>
> Now, if understand 'variant' correctly, then it seems to me that
'optional'
> could be implemented something like this (without run-time overhead on an
> ideal, but not "magical", compiler):
>
>     template<class t>
>     struct optional
>     {
>       ...
>     private:
>       variant<t,void> v;
>     };
>
Interesting note. I should think about this.

>
> Intent:
> - optional:      signaling errors/uncomputable results, lazy
initialization
> - variant:       safe union ???
> - any:           typeless programming (it seems like a "boxed value")
> - smart pointer: avoiding resource leaks/automatic finalization, exception
> safety
>
I've also used optional to pass optional parameters.

With the comments already added by Douglas and Kevlin, I think your tables
are accurate.

>
> I think that all of the above concepts should be further refined. For
> instance:
> - 'any' could probably make use of the 'vswitch' syntax.

I think any variant type could use this syntax. My own variant_t<> could use
it.

> - 'variant<T,void>' seems very close to 'optional<T>'.

Don't know for sure.

variant<T,empty> v ;
implies that v can hold a value of type T or type empty (or void, if that
would be possible).
According to variant semantics, it should be possible to assign empty() to
v.
So the empty type isn't any special; it just some sort of type that variant
can hold.

optional<T> opt ;
on the other hand, can only have type T. It dosen't have a second
'void/empty' type.
In other words, you cannot 'uninitialize' opt, which would be equivalent to
v = empty();

That is, I think that a variant which might have a 'void' type value isn't
exactly the same as a value that might be uninitialized.

>
> Assuming that optional and variant make it into Boost, I think that Boost
> should have documentation which describes the differences between these
> concepts and should perhaps include a decision tree for choosing the best
> alternative.
>
Certainly.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com