Re: [boost] Proposal --- A type-safe union

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-06-10 10:41:57

On Saturday 08 June 2002 05:44 am, Itay wrote:
> I'd like to propose a type-safe union library (aka: variant, discriminated
> union). The general concept has been thoroughly described by Andrei
> Alexandrescu at http://oonumerics.org/tmpw01/alexandrescu.pdf . My
> suggested class, Super_union, does not require RTTI to work properly, as
> all the important details are handled by compile-time algorithms.

We've discussed this quite a bit, but we have yet to see a full implementation 
for review. This is probably because there are many features we would like to 
see in a variant type. I've started a Wiki page to build a requirements 
document, and populated it with those requirements that I recall from 
previous discussions. The Wiki page is here:

  http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Variant

Here's the current requirements list from the Wiki page:

    * Interface should support construction and assignment from any of the 
types that the variant can hold.
    * Interface should be similar to that of boost::any for usability reasons.
    * Support for all types, e.g., types with nontrivial constructors, 
assignment operators, or destructors.
    * Stack allocation should be used/allowed so that the variant can be 
stored efficiently. 
    * Recursive types should be allowed, i.e., a variant can hold a value of a 
type that is constructed using the variant type. 
    * Incomplete types should be allowed.
    * Provide constructs for performing operations based on the type of the 
value stored in the variant that can check completeness of decoding. For 
instance, a 'typeswitch' or visitor construct that is guaranteed to fail at 
compile time if not all cases are covered. Pattern-matching constructs would 
be extremely interesting. 

As for your actual proposal:
  - The name Super_union is uninformative (what's 'super' about it?). I 
personally prefer just 'variant', but I'm sure there are other good names as 
well.

  - The visitor is fine, but there are simpler syntactic constructs that could 
be used. For instance, instead of 'visit_at' just use the function call 
operator. Also, the 'Visitor' class can be an implementation detail with a 
(more natural?) syntax like:
  Super_union<...> u0;
  // ...
  u0.visit(size_visit());

        Doug