C++ Logo


Advanced search

Re: std::variant - going from Alternative& to the enclosing variant&

From: Victor Khomenko <victor.khomenko_at_[hidden]>
Date: Fri, 21 Aug 2020 15:13:54 +0000
> 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.


Received on 2020-08-21 10:17:26