noexcept visitation for std::variant

Question

For some standard library classes, access to parts of their contents may legitimately fail. Usually you have the choice between some potentially throwing method an one that is marked noexcept. The latter spares the check on the precondition, so if you want to take the responsibility yourself, you can. This can be used under circumstances where using exceptions are not permitted or when fixing a performance bottleneck.

Example 1: std::vector element access:

std::vector<int> vec;
vec.at(n) // throws std::out_of_range
vec[n] // potentially UB, thus your own responsibility

Example 2: std::optional access:

std::optional<int> optn;
optn.value() // throws std::bad_optional_access
*optn // potentially UB, thus your own responsibility

Now on to std::variant. Directly accessing an alternative somewhat follows this pattern:

std::variant<std::string, int> var;
std::get<int>(var) // potentially throwing std::bad_variant_access
*std::get_if<int>(&var) // potentially UB, thus your own responsibility

But this time the signature changes, we have to inject * and &. The downside of this is that we don't get automatic move semantics. One more thing to keep in your mind...

But it gets worse if you have a look at std::visit(Visitor&& vis, Variants&&... vars). There is no noexcept alternative for it, although it only throws

if any variant in vars is valueless_by_exception.

This means for visiting variants you cannot choose to take the responsibility yourself, and if you have no choice and must avoid exceptions, you cannot visit std::variants at all with standard tooling! (apart from the terrible workaround of switching on variant::index())

To me, this looks like a pretty bad design oversight... or there a reason for this? And in case I'm right about the oversight, is there an initiative to fix this in the standard?

Answer 1

This means for visiting variants you cannot choose to take the responsibility yourself

Sure you can. The "valueless-by-exception" state can only happen if you assign or emplace a value into an existing variant. Furthermore, by definition, it can only happen if an exception is actually thrown during these processes. That is not a state that ever just happens to a random variant.

If you take responsibility to ensure that you either never emplace/assign to a variant, or that the types you use never throw in those circumstances, or that you respond to any exceptions from doing so in such a way that the variant that provoked it is not being talked to (ie: if bad_alloc is thrown, your application doesn't catch it; it just shuts down), then you don't have to care about this possibility.

Basically, if you're already coding to avoid exceptions, the non-noexcept status of visit is irrelevant. No variant will ever get into the "valueless-by-exception" unless an exception is thrown.