RE: [boost] optional vs variant vs any

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 13:35:31

----- Original Message -----
From: Douglas Gregor <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, August 30, 2001 3:02 PM
Subject: Re: [boost] optional vs variant vs any

> on Thursday 30 August 2001 10:18, you wrote:
> > 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();
>
> Sure you can:
>   v = optional<T>();
>
Good point.

> > 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.
>
> I think it is just a matter of definition. Having the current type of a
> variant<T, void> be void can be considered equivalent to having an
> uninitialized T value.
>
Not *just* a matter of definition.
The fact that a variant user can use a type which he/her uses as an alias to
void is *external* to the variant interface.
That is, variant itslelf -at least currently- doesn't handle an 'empty type'
any different. It is not aware of the semantic of 'empty'; so the
'emptyness' of variant<empty> is not part of the variant interface -or is it
part of its interface just as the exponent is part of the interface of
variant<double>'.

Unless, of course, you support 'empty' inside variant explicitely.

optional<T>, on the other hand, defines the concept of 'uninitialized' state
by itself, it is a property of its interface.

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