[boost] Re: generalization of types in variant

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-28 16:20:28

Fernando Cacciola wrote:

> "E. Gladyshev" <egladysh_at_[hidden]> escribió en el mensaje
> news:20031028185650.23854.qmail_at_web40811.mail.yahoo.com...
> 
>>--- Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
>>
>>[...]
>>
>>>How about not requiring a visitor overload for boost::empty?
>>
>>Sorry, I am not sure I understand.
>>Could you give some more details... piece of code?
>>
> 
> What I meant is to change variant so as to treat boost::empty specially and,
> for instance, never visit it.
>>From the user POV, this amounts to loose the requirement that the visitor
> must handle 'empty' as a visiting type.

Well, first of all, simply ignoring visitation is not possible because, 
in general, visitation may have a non-void result. Thus if we wish to 
"ignore" visitation, the closest thing would be to throw an exception.

So there are two choices:

1) Visitors need not handle the boost::empty case -- but if a variant
    containing boost::empty is visited, boost::bad_visit (or some other
    exception) is thrown. As always, variant can be checked for
    boost::empty content via the variant::empty method.

2) Visitors must handle the boost::empty case, as they must handle
    every other bounded type. [This is the current behavior.]

I prefer option 2 since it is "safer"; it forces the programmer to 
consider and explicitly handle (or ignore) the possibility of 
boost::empty content at compile-time.

By contrast, option 1 allows code to raise an error detectable only at 
runtime, regardless of whether such behavior was intended or not. It 
also gives special (unwarranted?) semantics to boost::empty; it is no 
longer "just another type." This may possibly complicate manipulation of 
variant objects in generic code.

 > Now, I do remember that this was originially a choice but it turned
 > out that instructing variant to have special knowldege of such a
 > singular type was very complex. I'm just suggesting that however
 > complex it might be, seems to solve some of this issues.

As I hope is clear from above, the issue is *not* about difficulty of 
implementation; rather, it is a question of design.

I do agree, however, that the need to explicitly handle boost::empty in 
visitors does somewhat complicate the use of boost::empty as an 
optimization. Perhaps the cannot_visit class I proposed elsewhere in 
this thread is a good solution.

I'm open to suggestions.

Eric