Re: [boost] optional vs variant vs any

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-08-29 19:47:24

From: "Douglas Gregor" <gregod_at_[hidden]>
> On Wednesday 29 August 2001 04:06, you wrote:
> > From: "Douglas Gregor" <gregod_at_[hidden]>
> > [... on optional ...]
> >
> > > I was recently working on a variant type that was intended to be created
> > > on the stack. I believe it is possible to do, though it isn't trivial
:).
> >
> > If I understand intention behind 'variant' correctly (I think of 'variant'
> > as a safe union that allows types with constructors and destructors) then
I
> > agree that it should be doable, but it is somewhat tricky to get it right:
> > - alignment
> > - exception safety
> > - safe/unsafe vswitch
>
> Alignment & exception safety are somewhat at odds.
                                                   ^ with each other?
Could you elaborate?

> For instance, if I have a
> variants a and b and I want to swap them, it is tough (maybe impossible?) to
> do this in an exception-safe manner for pathological types.

It seems to me that 'swap', and probably all the other operations as well,
could easily be made exception safe if a 'move' operation would be guaranteed
to be exception safe:

    // pseudo code
    swap(variant t_type t, variant u_type u)
    {
      uninitialized t_type tmp;

      // 3 exception safe moves:
      tmp <- t; // effectively: "new (&tmp) t_type(t); t->~t_type();"
      t <- u;
      u <- tmp;
    }

> Safe vswitch is the easy part :).

Yes, the only difficult part that I can see, at this point, is the syntax (of
both interface and implementation).

> > 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;
> >     };
>
> Yes, though replace "void" with a real (but useless) type, like:
> struct unused {};

hmn... Do you mean that 'void' is an illegal parameter for 'variant'?

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.

Questions:
- Can a 'variant' be 'empty'?
- What is the difference between 'variant' with and without 'void'?

I find it natural to think about 'variant' and 'void' like this:

                  default: ctor     | type   | state
  -----------------------+----------+--------+-------
  variant<t0,..,tn,void> | lazy     | void   | empty
  variant<t0,..,tn>      | strict   | t0     | !empty (always)

[Having 't0' as the default type means just that the default type is chosen
using some simple convention.]

> > - 'variant<T,void>' seems very close to 'optional<T>'.
>
> It is very close semantically.
>
> > - 'variant' and 'any' might or might not make use of some pointer syntax.
>
> Pointer syntax doesn't really make sense for variant or any, because there
is
> no fixed return type for either. For optional and smart pointer, there is
> only one possible type. This I think justifies the syntactic differences.

I was mainly thinking of the following syntax:

    !x         ...meaning...     x.empty()
    if (x)     ...meaning...     if (!x.empty())

And possibly:

    0 == x     ...meaning...     x.empty()
    x == 0     ...meaning...     x.empty()

However, the usefulness of the above syntax is not very clear. It seems to me
that 'vswitch' and 'cast' are the proper ways to use 'variant' and probably
'any', too.

Question:
- Is 'void' equivalent to 'empty'?

> > 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
>
> variant: discriminated union that also allows non-trivial
> constructors/destructors.

Ok.

> > Initialization:
> > - optional:      lazy
> > - variant:       ???
> > - any:           lazy
> > - smart pointer: strict (or this is how I see the matter)
> >
> > Should 'variant' support lazy initialization? Parhaps variant<> should
> > support being left unitialized only if 'void' is one of the variant types.
>
> variant uses lazy initialization, though I can't say I like it much.
>
> > What about 'any'? Should it be 'any_or_none' or 'optional_any'?
>
> The name "any" seems reasonable...

Yes, I like it best, too. However, with my understanding of English, 'any'
does sort of imply that it is always something, which, in a sense, is not
true, because 'any' can be 'empty'.

> > Copy semantics:
> > - optional:      value
> > - variant:       value
> > - any:           value
> > - smart pointer: reference, destructive copy or value (clone)
>
> Looks good. Not sure I agree with "destructive copy" or "value". I would
just
> say that smart pointers have reference semantics, but for objects with
> managed lifetimes.

Ideally (smart) pointers would simply have reference semantics, but there are
many "smart pointers" out there which make the case more interesting.