std::variant was introduced in C++17 as a type-safe union alternative designed to replace the error-prone and manually managed C-style unions. It enforces the invariant that it always holds exactly one of its specified alternative types, providing compile-time type safety and intuitive value semantics. This design theoretically guarantees that operations like std::visit or std::get always have a valid type to operate upon.
The valueless_by_exception state represents a specific failure mode where the variant holds no value due to an exception occurring during type-changing operations. This situation arises when the variant must destroy its current alternative to make room for a new one, but the subsequent construction of the new alternative throws an exception. Consequently, the object is left without a valid active member, breaking the standard variant invariant temporarily.
The solution provided by the standard is to permit this singular invalid state specifically to maintain basic exception safety guarantees. While in this state, the variant remains destructible and assignable, allowing resources to be cleaned up and new values to be placed into the storage. To fully recover from this condition, one must successfully assign or emplace a new value, which restores the invariant by establishing a valid alternative and resetting the internal state tracking.
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // may throw bad_alloc } catch (...) { assert(v.valueless_by_exception()); v = 42; // Recovery: valid again }
Consider a high-frequency trading system processing market data messages represented as std::variant<PriceUpdate, OrderCancel, TradeExecution>. During a memory-constrained scenario, an attempt to assign a large TradeExecution object throws std::bad_alloc after the variant has already destroyed the previous PriceUpdate to make space. This sequence results in a valueless variant propagating through the pipeline, potentially causing cascading failures if downstream code assumes valid data is present.
One solution involved wrapping every variant access with valueless_by_exception() checks and manual recovery logic before any visitation or retrieval operations. This approach provided explicit safety against undefined behavior but cluttered the codebase with defensive checks at every usage point, significantly degrading readability and introducing unacceptable latency in the critical trading path.
Another approach considered using std::optional<std::variant<...>> to externalize the empty state outside of the variant itself. While this preserved the variant's internal invariant by ensuring the inner variant always held a valid type, it introduced a second layer of indirection and required double-dereferencing for every access, complicating the API surface and potentially impacting cache locality during high-throughput processing.
The team ultimately selected std::monostate as the first alternative in the variant type list, effectively reserving an explicit "empty" state within the variant's normal type system. This choice eliminated the possibility of the valueless state entirely because the variant could always fall back to holding std::monostate instead of becoming valueless, ensuring index() always returned a valid position and std::visit always dispatched successfully to either real data or the empty state handler.
The result was a robust message processor that handled allocation failures gracefully by transitioning to the monostate alternative rather than an exceptional invalid state. This design maintained strict type safety without requiring runtime checks for valuelessness or suffering from double indirection overhead. Developers could rely on the variant always being visitable, with the monostate handler acting as a no-op or default behavior for empty messages.
Why does std::variant permit the state valueless_by_exception despite violating the general design principle that a variant should always hold one of its specified types?
The standard prioritizes strong exception safety over maintaining the strict invariant at all costs. When changing the held alternative, the variant must destroy the old value before constructing the new one to prevent resource leaks or double ownership issues. If this new construction throws, the variant cannot roll back to the previous state because that storage is already destroyed, nor can it complete the transition to the new state. The valueless_by_exception state serves as a necessary escape hatch indicating the object is destructible and assignable but holds no valid alternative, preventing undefined behavior that would result from pretending the old value still exists or leaving the storage uninitialized.
How does std::visit behave when invoked on a variant that has entered the valueless_by_exception state, and why does this differ from accessing a variant holding std::monostate?
std::visit immediately throws std::bad_variant_access when encountering a valueless variant because the active type index is variant_npos, which does not map to any visitor overload. This differs fundamentally from std::monostate, which is a legitimate albeit empty type occupying a specific index position within the variant's type list. A visitor can provide a specific overload for std::monostate to handle empty states gracefully as part of normal control flow. The valueless state represents a true error condition where type information is entirely lost, whereas monostate represents a valid, intentional empty state within the type system that participates in the visitation dispatch mechanism.
Can a variant recover from the valueless_by_exception state without destroying and reconstructing the variant object itself, and what specific operations facilitate this recovery?
Yes, recovery is possible through assignment or emplace operations without needing to destroy the variant wrapper itself. When you execute v = T{} or v.emplace<T>(args), and the construction of type T succeeds, the variant exits the valueless state and holds the new type. This works because these operations are defined to establish a new active alternative, effectively reinitializing the storage with a valid value and resetting the internal index from variant_npos to the position of T. Merely reading from the variant or calling non-modifying observers will not change the state; only a successful operation that places a new value into the storage can restore the class invariant and reset the valueless flag to false.