RE: [boost] optional vs variant vs any

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 12:24:25

----- Original Message -----
From: Vesa Karvonen <vesa.karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, August 30, 2001 9:15 AM
Subject: Re: [boost] optional vs variant vs any

> [SNIP]
> > > 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
seems
> > > 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
when
> > 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
return
> both 't' and 'void' objects (nor 'empty' objects).

Right

>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,
uninitialized)"

> 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?

> then
> according to many modern programming languages and language designers,
such
> semantics should be avoided in favor of type safe semantics. Both
'optional'
> and the C/C++ pointer are not type safe. 'variant', on the other hand, is
type
> safe.
>
Could you elaborate, please?

> > Perhaps for optional<T>, any, and a smart pointer, yes. I'm not sure
that
> > 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
other
> than to 'optional'.
>
Yes, indeed.

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