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:
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
* 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
- 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk