Subject: Re: std::variant - going from Alternative& to the enclosing variant&
From: Victor Khomenko (victor.khomenko_at_[hidden])
Date: 2020-08-21 10:13:54
> 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.
STD-DISCUSSION list run by email@example.com
Older Archives on Google Groups