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

From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-06-11 10:25:11

Douglas Gregor wrote:
[snip]
> 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
> 

It's nice to know I am not the only one who thinks a
type-list based union is a good idea :)

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

What about automatic casting from non-specified types?
(For example: initializing a union of <float, string>
with a double value). Personally, I think this
behavioral detail should be specified by a policy. 

In general, I see four separate, policy-controlled,
aspects:

1) Storage: (i) boost::any (ii) on-stack
2) Automatic casting: (i) never, (ii) cast to the
first type possible, (iii) cast if only one possible
type found
3) Assignmenmt error: (i) Compile-time error, (ii)
initialize with default value of first type

The fourth aspect relates to the issue of variant to
variant assigmnet:
   Variant<List1> u1;
   Variant<List2> u2;
   ...
   u1 = u2;  //Problem(?): u2's held type may be
invalid  
             //            for assignment into u1

4) Variant to variant assigmnet error: (i)
Compile-time error if List2 is not a sub set of List1.
(ii) Run-time error (iii) assign the default value of
the first type on List1

[snip]

>
>     * 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.
Can you clarify on these two points?

[snip]
> 
> 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.
I used 'Super_union' as a "project name" which
specifies a concrete implementation. As for the final
name of this component, I agree with you: 'variant' is
most appropriate.

> 
>   - 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. 
The function call operator cannot be static, which is
somewhat restrictive.

> Also, the 'Visitor' class can be an implementation
detail with a 
> (more natural?) syntax like:
>   Super_union<...> u0;
>   // ...
>   u0.visit(size_visit());
> 

This syntax is indeed more natural, when the visit
policy is stateless. However, if we make go() to
return *this, we end up with a very clean way for
applying the operation to multiple objects:

   typedef Super_union<The_list> Concrete_union;
   Concrete_union::Visitor<size_visit>::type
size_visitor;

   // ...

   int result =
size_visitor.go(u0).go(u1).go(u2).total_;

Thoughts?

-Itay

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com