From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 12:24:25
----- Original Message -----
From: Vesa Karvonen <vesa.karvonen_at_[hidden]>
Sent: Thursday, August 30, 2001 9:15 AM
Subject: Re: [boost] optional vs variant vs any
> > > What do you think about the following table?
> > >
> > > default: ctor | type | state
> > > -----------------------+----------+--------+-------
> > > optional<t> | lazy | t | empty
> > > any | lazy | void | empty
> > >
> > > Notes:
> > > - 'optional' and 'any' can be 'empty'.
> > > - At this point, to me, the (contained) type of 'optional<t>' always
> > > to be 't'.
> > > - 'any' has chosen to use 'void' as the type of the 'empty' state.
> > Looks good. The contained type of optional<T> is essentially irrelevant
> > it is empty, so I think "undefined" is reasonable.
> I also considered 'undefined', 'void' and 't'.
I think the right term is 'uninitialized'.
> 'void' does not seem
> reasonable, because the interface of optional can not simultaneously
> both 't' and 'void' objects (nor 'empty' objects).
>Also, it isn't really the
> type that is 'undefined'. It is the operations that return 't' that are
> undefined when the state of an 'optional' is 'empty'. This seems very much
> like the case with dereferencing a null pointer.
I would say that "it is the *value* which is undefined (or better yet,
> Now, assuming that 'optional' has semantics not unlike the C/C++ pointer,
"not unlike the C/C+ pointer" means "like the C/C++ pointer" right?
> according to many modern programming languages and language designers,
> semantics should be avoided in favor of type safe semantics. Both
> and the C/C++ pointer are not type safe. 'variant', on the other hand, is
Could you elaborate, please?
> > Perhaps for optional<T>, any, and a smart pointer, yes. I'm not sure
> > should be try for variant, because it will never be "empty" per se.
> I think I'm now convinced that the pointer syntax should not be used for
> 'any'. I think that in order to avoid confusion, the syntax should only be
> used for pointer like semantics.
Do you include optional<> in this category?
> It seems that 'variant' and 'any' are semantically much closer to each
> than to 'optional'.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk