From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 13:35:31
----- Original Message -----
From: Douglas Gregor <gregod_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
> > would be possible).
> > According to variant semantics, it should be possible to assign empty()
> > v.
> > So the empty type isn't any special; it just some sort of type that
> > 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
> > v = empty();
> Sure you can:
> v = optional<T>();
> > That is, I think that a variant which might have a 'void' type value
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk