> I don't think so. The magic-function you suggest would seemingly need to be
> told what kind of a variant to convert to.
 
True. One can do static sanity checks, that the type is indeed a variant and that it has the type of the function's argument as an alternative. Moreover, you'll have to do something with the object returned by the function - e.g. assign it to some variable, and if the type is wrong, you'll get a type mismatch error. So even though one can theoretically make this mistake and still get the code compiled, I think the danger is minimal in practice - I'd compare this to calling a wrong function by accident.

(Interestingly, the value of the returned reference would likely be the same for ANY variant (we just do a cast!), so it's only about the type of the returned reference. But I explicitly refrain from saying that this somehow increases the safety :-)


> In the approach I suggest, that's your parameter type. The error possibility of
> getting the variant type wrong is not there; the type and value of the variant
> is statically correct, as opposed to possibly being incorrect at run time.

I agree with this. Moreover, your solution avoids disadvantages (1) and (2) in my initial posting. However, there are some drawbacks:
  * having two different visit functions may be confusing for the user
  * if only some but not all operator()s need access to the variant, all operator()s will still need to have an extra parameter.

Well, anyway, I think either of these two solutions would be acceptable, and are much better than work-arounds.

Victor.