Allow overriding monostate and bad_variant_access to improve compatibility with other C++11+ header-only libraries

[MostafaNanticock]

Description

We are using variant-lite in a project alongside tl::optional and other header-only C++11+ compatibility libraries. To provide a unified interface for downstream users, we expose them under a std_compat namespace:

namespace std_compat
{
    template <class T>
    using optional = tl::optional<T>;

    using tl::bad_optional_access;
    using tl::in_place_t;
    using tl::in_place;
    using tl::nullopt;
    using tl::nullopt_t;
    using tl::make_optional;
    using tl::swap;
}

namespace std_compat
{
    template <class... Types>
    using variant = nonstd::variant<Types...>;

    using nonstd::bad_variant_access;
    using nonstd::get;
    using nonstd::get_if;
    using nonstd::holds_alternative;
    using nonstd::visit;
    using nonstd::variant_npos;
    using nonstd::variant_size;
    using nonstd::variant_size_v;
    using nonstd::variant_alternative;
    using nonstd::variant_alternative_t;
}

Problem

1. monostate conflicts:
   Both tl::optional and variant-lite require a monostate type.
   On MSVC 17.10.35122 (with C++17 enabled), the CRT also provides std::monostate.
   This results in three different monostate definitions that are not interchangeable, causing compilation errors when the libraries are used together.

2. bad_variant_access mismatch:
   The MSVC CRT provides std::bad_variant_access.
   variant-lite uses its own nonstd::bad_variant_access.
   Third-party code using our std_compat::variant must catch both exceptions to be safe, which is error-prone and unintuitive.

Proposed solution:

Add configuration macros to variant-lite to allow users to override the monostate and bad_variant_access implementations with their own (or the standard library’s) versions.

For example:

#ifdef variant_CONFIG_BAD_VARIANT_ACCESS
using variant_CONFIG_BAD_VARIANT_ACCESS;
#else
class variant_nodiscard bad_variant_access : public ::std::exception
{
public:
#if variant_CPP11_OR_GREATER
    virtual const char* what() const variant_noexcept variant_override
#else
    virtual const char* what() const throw()
#endif
    {
        return "bad variant access";
    }
};
#endif

#ifdef variant_CONFIG_MONOSTATE
using variant_CONFIG_MONOSTATE;
#else
class monostate {};

struct in_place_t {
    explicit in_place_t() = default;
};

static constexpr in_place_t in_place{};
#endif

Benefits:

• Avoids duplicate/conflicting type definitions when integrating with other compatibility libraries.
• Allows seamless use of the standard library’s monostate and bad_variant_access when available.
• Reduces exception-handling boilerplate for downstream users.
• Keeps variant-lite flexible without breaking existing behavior.

If this approach does not conflict with any existing design decisions or constraints in variant-lite, I’m happy to prepare and submit the implementation as a PR.

[martinmoene]

@MostafaNanticock , thanks for your proposal.

I appreciate the idea.

Replacing the simple classes bad_variant_access and monostate in variant-lite might work out ok.

However in_place_t and in_place as you present it are not as they are implemented in variant-lite. The reason for this is making these work with C++98 (IIRC). Also note that the implementation of in_place is shared between any-lite, expected-lite, indirect_value lite, optional-lite and variant-lite.

Without a working proof of concept, I'm a bit weary to start this path.

Kind of funny (and understandable) to see this issue with optional-lite, instead for variant-lite :)

[MostafaNanticock]

@martinmoene
Sorry for the confusion, but every repo in your account has the prefix -lite and I'm using all of them (Thank you so much for these amazing repos BTW) 😅.

For some reason i included the in_place and in_place_t in my code snippet, my bad. I don't need to be able to replace them for now, maybe this can be delayed to a separate issue if we ever faced any problems that required such effort.

For now, I'll implement a proof of concept on my fork of the repo and let you know to see what you think.

One last thing, what should i do about this stray Issue that i opened here? 😅
Should i close it here and recreate it in the variant-lite repo?

[martinmoene]

No problem :)

You can create a PoC, followed by a PR in variant-lite and mention/link this issue there.

I've done that already: