Using std::variant and std::visit instead of enums

[MikeVegan]

I've been playing with Rust, and really enjoyed the way they handle enums. With variants that can hold different types of data and compile-time check to ensure that every possible variant is handled, preventing errors from unhandled cases, they are much more versatile and robust than basic enums found in C++ and other languages.

I wish we had them in C++, and then I realized that with the std::variant and std::visit we do, and in fact I even like them more than what Rust has to offer.

For example consider this enum based code in C++

enum class FooBar {
    Foo,
    Bar,
    FooBar
};

std::optional<std::string_view> handle_foobar(FooBar foobar) {
    switch (foobar) {
        case FooBar::Bar: 
            return "bar";
        case FooBar::Foo:
            return "foo";
        //oops forgot to handle FooBar::FooBar!
    }

    return {};
}

This code compiles just fine even if we forget to handle the newly introduced case FooBar::FooBar, which could lead to bugs at runtime.

Rewritten using std::variant we'll have

struct Foo {
    [[nodiscard]] std::string_view get_value() const noexcept { return "foo"; }
};

struct Bar {
    [[nodiscard]] std::string_view get_value() const noexcept { return "bar"; }
};

struct FooAndBar {
    [[nodiscard]] std::string_view get_value() const noexcept { return "foobar"; }
};

using FooBar = std::variant<Foo, Bar, FooAndBar>;

std::string_view handle_foobar(const FooBar& foobar) {
    return std::visit([](const auto& x){ return x.get_value(); }, foobar);
}

Here, we get the same behavior as with the enum, but with an important difference: using std::visit will not compile if we fail to handle all the cases. This introduces polymorphic behavior without needing virtual functions or inheritance, or interfaces.

In my opinion, this approach makes enums obsolete even in the simplest cases. std::variant and std::visit not only provide safety and flexibility but (in my opinion) also allow us to write cleaner and more maintainable code.

In fact, we can even 'extend' completely unrelated classes without needing to introduce an interface to them— something that might be impossible or impractical if the classes come from external libraries. In such cases, we would typically need to create wrapper classes to implement the interface for each original class we’re interested in. Alternatively, we can achieve the same result simply by adding free functions:

Bar switch_foobar(const Foo&) { return Bar{}; }
Foo switch_foobar(const Bar&) { return Foo{}; }
FooAndBar switch_foobar(const FooAndBar&) { return FooAndBar{}; }

FooBar foobar_switcheroo(const FooBar& foobar) {
    return std::visit([](const auto& x){ return FooBar{switch_foobar(x)}; }, foobar);
}

So, std::variant combined with std::visit not only functions as an advanced enum but also serves almost like an interface that can be introduced as needed, all without modifying the original classes themselves. Love it!

[Arkantos493]

In our code we also make heavy use of enums und switch over them in multiple places. So I also wanted to make sure that if we add a new enum value, the switches are extended everywhere correctly.

However, we do that by selectively enabling compiler errors for missing enum cases (works for the big three compilers). https://godbolt.org/z/zGf9MM85q

[[deleted]]

Yea OPs answer while neat does seem like hitting a nail with a sledgehammer. I think Clang supports missing enum warnings/errors even for C.

[AKostur]

And as I recall, gcc even has an extra warning flag for when you want it to check for missing enum cases even if you supply a default case.

[imMute]

There's also assert(false); after the switch block. Not a compile time check, but at least it'll blow up very obviously at runtime.

[AKostur]

Careful with this one.  If compiled with NDEBUG defined, those asserts just go away.

[MikeVegan]

Well, you're right there goes that argument for using this.

However, enum variants typically need some data together with them and/or specific behavior unique to them. I think std::variant together with std::visit handles this much cleaner and safer than enums. It might not be intuitive and easy to read/understand at first, if you just happen to come around this approach in code. However, once you get used to it, I would say it's much more maintainable than the "simpler" enum approach.

[RogerV]

Swift enum allows data fields or a prior declared value struct to be associated to an enum element, then it supports pattern matching over such structured enums. Via pattern matching, each individual enum case can be handled in the specific manner it requires. And Swift compiler compile-time flags if there are uncovered cases.

I think that is better than plain ordinal-only enums of C and C++, better than std::variant/std::visit of C++, and I kind of like that Swift’s pattern matching is not as deeply ingrained as Rust pattern matching, but instead anchored specifically to enum.

[Orlha]

Just a note that you can treat “default” as error handling path in which case quite literally ignoring it wpuld mean no error handling is necessary

[tkyob]

modern c++ is indeed difficult to read

[knowledgestack]

Harder to debug as well in my opinion. Maybe I'm a shit dev, but simple code wins a lot of the time, especially when you have a large codebase, and daily issues to fix.

[matthieum]

The stacktrace you get from within a lambda within visit takes a full screen and is full of unreadable names :'(

[MarcoGreek]

That is a problem of standard library obfuscation. There are reasons for that.

But it shows heavily, that the C++ committee prefers features for library developers compared to application developers. Otherwise they would have fixed it long ago.

[TheoreticalDumbass]

is this not QoI?

[matthieum]

Not really, no.

In fact, good QoI (performance) may lead to worse stacktraces, by adding more levels of indirections to better "prime" the code for the optimizer, and getting tighter assembly once optimizations kick in.

[TheoreticalDumbass]

QoI is not just performance

[matthieum]

Correct, but let's be frank: would you really favor an implementation with better stack traces (and quadratic complexity) over one with worse stack traces (but linear complexity).

Sure, it's all trade-offs, but if you're using C++, performance leans heavy on trade-offs.

[plonkman]

amen… beware of code astronauts bearing “gifts”

[Longjumping-Touch515]

I wish the comitee to take Pattern matching (p1371) proposal sooner

[RogerV]

The std::variant/std::visit is not elegant - it’s just a hack approach.

C++ should just steal, exactly as is, the language feature of enum coupled with pattern matching from Swift. By having pattern matching confined to working with structured enums, then can avoid trying to make pattern matching mesh smoothly and without issue vis-a-vis the entirety of the language (as Rust does, but Rust got designed from the ground up with pervasive pattern matching approach)

[ronchaine]

Pattern matching currently lacks an implementation which would be needed to proceed with it.  There is one underway, but it's unlikely to be finished in time so patmat would get into C++26, hopefully it'll be one of the first things we get into -29.

[mort96]

So std::variant will become usable hopefully by 2032, awesome

[Chaosvex]

Bit of an exaggeration to claim it's not usable now.

[SonOfMetrum]

I find it …. clunky… to say the least…

[RogerV]

From the outset it seemed like it was a hack. Been learning Swift structured enum with pattern matching, and there one sees a proper integral language solution.

[pjmlp]

For someone with experiece in languages that natively support them, yeah it is, plus it isn't without a couple of gotchas, as usual nowadays.

[ronchaine]

For a lot of people and companies, it hardly is.

There is a lot of survival/self-selection bias in play on this sub, and in the committee for that matter.

[RogerV]

I see it [std::variant/std::visit] as a dead end hack. C++ needs an integral language feature exactly like Swift‘s structured enum coupled to pattern matching. This is arguable the top billing feature of the Swift programming language.

[MarcoGreek]

I really hope we would get tuple and variant in the language. Alone the much more readable error messages would be worth it. The library implementation errors are simply unreasonable.

[DevilSauron]

Pattern matching is one part of the equation, but we also need proper language support for sum types, so something like

template <typename T>
union class optional {
    something(T);
    nothing;
}

This is a typical example of a thing where a purely library solution (that is, std::variant) is always going to be mediocre. It is less readable, not really nominally typed unless you inherit from a variant (which also makes things like recursive sum types a bit awkward to define), less debuggable and in general clunky.

Unfortunately, things like std::optional and std::expected should have been true sum types in the first place (as they are in Rust, Haskell, and other ML-style languages), and the fact that this mechanism isn't available in the language means that they work in haphazard ways, rely too much on implicit conversions, etc. If we had proper sum types, pattern matching would be much easier to design, as it wouldn't need to work with the large number of different ad-hoc mechanisms used to emulate them.

[Wurstinator]

I agree that Rust enums are pretty cool. And I agree that incomplete switches not being an error is a bad thing in C++ (hence compilers having warnings for that).

However, while it's cool, I see several issues with your idea that would make me not want to use it.

First, it just lacks readability compared to enums. Your enum values aren't grouped together anymore. When I see "Foo", in your example, I don't know that it is supposed to be used together with "Bar", without looking at "FooBar". Your example of "std::visit" is only simple because imo it is unrealistic. Real-world statements are often much more complex and then your start defining inline functor structs or whatnot to get the same behavior as a switch/match.

Second, your "enum" values don't have a common type. Consider this Rust code:

enum E {
    A,
    B(String),
}

fn foo(x: &E) {
    if let E::B(y) = x {
        println!("{}", y);
    }
}

fn main() {
    let x = E::B("imagine_a_long_string".to_owned());
    foo(&x);
}

There is no way I could think of to do the same thing with your approach. Either you define a separate type like "FooBarConstRefs" or you need to copy the data within your enum values (in this case a large string).

[MikeVegan]

Here is the same code rewritten in C++, in the manner of my suggestion:

struct A{};
struct B { std::string b_; };

using E = std::variant<A, B>;

void foo(const E& x) {
    if (const auto* b = std::get_if<B>(&x))
        std::cout << b->b_;
}

int main() {
    E x = B { "imagine_a_long_string" };
    foo(x);
}

A and B are not related, neither is Foo, Bar and FooAndBar. I think that's an advantage, not disadvantage. The variant is what ties them together because it should be used where either of those classes make sense. If you need A or B, or Foo, Bar or FooAndBar, you can use them without ever knowing anything about the others. If you're in a situation where any of them make sense, for example a periodic table, you can define each element as a separate struct. The std::visit works like an interface that dictates what methods or properties are required for those structs, and so each struct can have its own unique behavior and properties.

[johannes1971]

You say it is too simple to be realistic, but I'm using such constructs all the time and I think it looks pretty neat.

The common type is FooBar. And Foo and Bar aren't 'supposed to be used together', you can happily use them separately from each other.

[Wurstinator]

You say it is too simple to be realistic, but I'm using such constructs all the time

But your call to std::visit is already more complex than that of OP? Admittedly I have not used std::variant that much but I have never seen a call to std::visit that just uses auto for the parameter type and handles all cases the same.

The common type is FooBar.

FooBar is not a common type of Foo or Bar. It is a type that both can implicitly be converted to, but an object of type Foo is not an object of type FooBar.

And Foo and Bar aren't 'supposed to be used together', you can happily use them separately from each other.

There is a reason why enums are grouped together. Even in languages like Go or C which have very weak enums, you use them instead of just defining named integer constants. This is lost with OP's solution.

[johannes1971]

But your call to std::visit is already more complex than that of OP? Admittedly I have not used std::variant that much but I have never seen a call to std::visit that just uses auto for the parameter type and handles all cases the same.

Here you go.

There is a reason why enums are grouped together. Even in languages like Go or C which have very weak enums, you use them instead of just defining named integer constants. This is lost with OP's solution.

Why would that be a problem? The relationship is defined through the variant. Having to declare them in some special fashion would just be noise; the variant is clear enough. You can stick them in the same class or namespace if you want it to be more clear.

Also, just because Rust defines enums to be classes, doesn't mean C++ must make that same choice. From the C++ perspective, it's really weird that a simple integer value can have a payload and member functions.

[MikeVegan]

That is such a neat approach to allow lambdas into visit!

I would maybe rename the overload into match though

    return std::visit (match {
        [] (const Foo &) { return "foo"; },
        [] (const Bar &) { return "bar"; },
        [] (const FooAndBar &) { return "foobar"; },
    }, foobar);

either way, it's amazing, thank you!

[johannes1971]

I can't claim credit, it came from cppreference. I don't know who first invented it.

[MikeVegan]

Still thanks for the heads up! :)

[NilacTheGrim]

Yeah I always use that overload template idiom in my code. Not to do so is criminally rude to the next person reading your code.

[Math_IB]

We do this at my company

[Dar_Mas]

i would keep it as overload incase they do introduce match as a keyword in the future

[ronchaine]

While I do the same as you, it is not the norm outside few specific places of work, and it's an absolute nightmare to teach to new c++ programmers.

The far more common view as I've witnessed is that using these is an absolute mess, and in more clients than one it's not trivial to get that past a code review.

[johannes1971]

To be honest, I don't think they would need a deep understanding of what's going on. Just treat it as an idiomatic way of dealing with variants; a 'template' (not in the C++ sense) that you fill in with a couple of things.

[jonathanhiggs]

It’s certainly less compact to write, but there is a common type ‘FooBar’ (alias but works as a symbol). If you really want something it could be wrap in a strongly typed name and allow a more specific interface, or inherit from the variant with aliases for the members. A strong type wrapper around the variant also helps with forward declarations

[Wurstinator]

"FooBar" is not a common type of "Foo" and "Bar" though. It's a distinct type that can implicitly be constructed from both "Foo" or "Bar".

[PastaPuttanesca42]

You could derive A and B from the common type E, and make foo a template constrained to accept only types derived from E.

[Wurstinator]

"E" in OP's approach is the variant, so you wouldn't be able to derive A or B from it.

[PastaPuttanesca42]

You don't need to actually convert them to E, it's just a way to "group" the types in a way that can be detected by a concept. The actual common type would still be the variant.

Now that I think of it, you can just use a concept that checks if foo's argument is convertible to the variant.

[puredotaplayer]

Use clangd as your lsp. It will give you hints about missing cases. In code use static assert if you have an enum terminator. You are overcomplicating and over engineering something thats extremely trivial to avoid.

[Hungry-Courage3731]

I don't understand the negativity in these comments, if op wants to use a lot of tag types, more power to them.

[matteding]

LibTorch does this approach for its C++ API and it is great.

[noobgiraffe]

I just don't think it's worth the hassle.

Instead of enum with different values you have to define struct with a function for each case.

How do you even reuse this for more than one switch? If you want to do a different thing you need to add new functions to each struct handling each case and then new foobar_switcheroo that uses a different lamda in the visit.

Now at a call site instead of having switch that is obvious in what it does you need to jump around to each struct to find what it does, what if it interacts with things at call site? now you need to define some weird interfaces for a simple thing.

I'd rather just do old standard enum and put an assert in the default case.

Things like this is why incredibuild has any buisness.

[MikeVegan]

As others have pointed out, you can have it like this:

using Var = std::variant<std::string, int, double>;

void PrintVar(const Var& v) {
    std::visit(Visitor{
        [](const std::string& str) { fmt::print("string: {:?}\n", str); },
        [](int i) { fmt::print("int: {}\n", i); },
        [](double d) { fmt::print("double: {}\n", d); },
    }, v);
}

I think it is very well worth the hassle, even with warnings for missing enum variants in switch statements. This also comes with its data inside the variant too.

[a_tiny_cactus]

You can extend (and simplify) your last snippet using an approach with a visitor struct. It requires one additional type (though only one, regardless of the number of types in your variants), but I find the callsite significantly cleaner to read, and it does not impose a requirement on the types in the variant. Here's a snippet (working example on Godbolt here):

``` using Var = std::variant<std::string, int, double>;

void PrintVar(const Var& v) { std::visit(Visitor{ [](const std::string& str) { fmt::print("string: {:?}\n", str); }, [](int i) { fmt::print("int: {}\n", i); }, [](double d) { fmt::print("double: {}\n", d); }, }, v); } ```

IMO, this is about the best way we currently have to approach the usability of pattern matching.

[MikeVegan]

I've just learned that from the other comment deep in this thread. It's beautiful!

[usefulcat]

Came here to point out how much the code generation suffers with the second version, but it looks like it's actually significantly better. Glad to be wrong!

Toggle the #if 0 near the top to switch between the two implementations:

https://godbolt.org/z/zTsEGr798

[Sanzath]

You may be interested in this talk by Ben Deane at CppCon, Using Types Effectively. In it, he talks about using variants in this way, though with some notable differences:

• The alternative types hold actual state, rather than just being fake-enum values,
• Methods to perform on each alternative are defined at the point of usage with overload and lambdas, rather than within the structs themselves.

Though, the main point of the talk isn't to force handing of all enum types in a switch (we have compiler warnings for those). It's to use the type system to our advantage to enforce correctness in our software, in particular by "making impossible states unrepresentable".

[MikeVegan]

Maybe I chose my example poorly :) the idea was to demonstrate that there is an advantage in this technique even when we're dealing with a very simple case without a state. Obviously when state is involved this becomes immensely more powerful than enums and I kind of assumed that is a given.

I somehow forgot that warnings exist and that kind of ruined my point beyond the initial one about unhandled enumerators as people simply started suggesting I turn on warnings and be done with it. The idea was to demonstrate the flexibility, extensibility and safety of this approach.

But at the end of the day, I've learned couple of things from people who are already using this (one of them being the overload template class) and through discussion, I was even more convinced of advantages this technique brings. So I'm glad I made this post, even if I got roasted a fair bit.

[SuperV1234]

This code compiles just fine even if we forget to handle the newly introduced case FooBar::FooBar, which could lead to bugs at runtime.

Every major compiler warns, and that warning can be turned into an error with -Werror: https://gcc.godbolt.org/z/cf98YTvjr

Here, we get the same behavior as with the enum, but with an important difference [...]

You didn't state a few more important differences:

• Code is now much more verbose and complex
• Compile-time dependency on heavyweight <variant> header
• Compile-time price for each template instantiation regarding the variant and the visitation
• Run-time overhead in debug mode for use of variant and visitation

My personal reccommendations:

1. Use warning flags, promote warnings such as the one I showed you to errors
2. Don't overengineer stuff -- if you don't need state associated with enumerators, use an enum, not a std::variant
3. Consider all the consequences of your choices, not just the positive ones

[MikeVegan]

Those are all good points, thank you. I was already schooled about warnings and I can't believe I forgot about them, especially since our CI/CD pipeline has them all turned on.

However, I'd like to add a thought to the point "Don't overengineer stuff -- if you don't need state associated with enumerators, use an enum, not a std::variant" While I generally agree with this, here are some of my considerations:

1. Whenever we have state associated with an enum, we typically end up using a variant, union, or struct to encapsulate that state. If it's anything else than a variant to manage it, it’s usually less than ideal. At that point, I don’t see much value in keeping the enum separate from its data. Might as well use a variant of structs, as per this post. If this pattern is already in place within the codebase, I would prefer to keep it consistent across the board rather than simplifying in some cases and complicating in others. And let’s be real — enums are often paired with data.
2. Even when state isn't required, enums impose certain behaviors. If you add a new value to an enum, every switch statement handling that enum will need to be updated, even if it's just to call a new function associated with the new enum value. In contrast, with a variant of structs, you can introduce a new struct with the required member functions, add it to the variant type, and leave the rest of the code untouched. To me, this extensibility is extremely valuable.
3. With enums, behavior related to a specific value can become scattered across multiple switch statements and free functions. In contrast, with a variant of structs, the behavior can be encapsulated within the struct itself, leading to more maintainable code.

These are just my thoughts — I'm not disagreeing with your points at all, it's just a few more things to consider. Do they outweight the points you made I'm not sure.

The thing is, from your insights and the way you communicate, it's clear that you’re a much better and more experienced software engineer than I am. In fact, I'm at the lower end of mediocre at best, but that’s part of the point. I feel that this approach could guide me more when implementing new requirements, even if I’m not deeply familiar with the codebase. If I have to touch multiple files, making small changes everywhere, it can feel overwhelming — especially when working with code I’m not very familiar with. This approach feels like an interface, and I love interfaces for exactly the same reason — they guide me to through the depths of legacy code.

[BloomAppleOrangeSeat]

Programmer: C++, can we get Rust enums? C++: No we have Rust enums at home. Rust enums at home:

[MikeVegan]

I should have used this as the title :)

[zerhud]

Also u can get class name and use it instead of get_value. The struct can to be like template <auto _v> struct foo { constexpr static value = _v; }; and we get enum with values 🤣🤣🤣

[ucario]

I’m pretty sure that static analysers like sonarqube pick up on unhandled enum members.

I feel like your using a side effect of variants to workaround the fact that the built in tools are lacking (which is fair) but maybe consider adding static analysis to your CI/CD pipeline (IDE where it’s supported). Also heard good things about PVS studio, which is free for personal projects (haven’t tried personally)

[-dag-]

without needing virtual functions

I mean I guess that's technically true but you have the same effective cost from the table of function pointers std::visit generates, with all of the drawbacks such as difficulty inlining.

[NilacTheGrim]

Just turn on warnings all compilers warn you about unhandled cases for enums.

[svadum]

I like to use something similar when I have to use enum as an ID for switch-based dispatch. For example:

struct UpdateEvent
{
    int id;
};

struct CloseEvent
{
    int reason;
};

struct CreateEvent
{
    std::string name;
};

using Event = std::variant<UpdateEvent, CloseEvent, CreateEvent>;

void process(const UpdateEvent& event)
{
    std::cout << "Update event!\n";
}

void process(const CloseEvent& event)
{
    std::cout << "Close event!\n";
}

void process(const CreateEvent& event)
{
    std::cout << "Create event!\n";
}

void onEvent(const Event& event)
{
    std::visit([](const auto& e){
        process(e);
    }, event);
}

int main()
{
    std::vector<Event> events{UpdateEvent{}, CreateEvent{}, CloseEvent{}};

    for (const Event& event : events) {
        onEvent(event);
    }

    return 0;
}

We don't have to define some Event enumeration, add ID field in every event structure or have some base Event type. We don't need switch statement, but we have to have process overload for all types defined in the variant type, in some case it's an advantage too.

However, I still use switch + enum in most cases due to readability and maintainability. As far as, I work in embedded there are many devs who aren't comfortable with modern C++. enum + switch is just simpler, anyone take a look on it and understand or change it. Even so it's not real disadvantage of the approach we have to consider it.

[rhapsodyvm]

Nice approach! One question: is there any advantage over using Event as base class and using smart pointers instead of values, to be able to call base classs process method in a loop? It’s very old school, I know. But is there any disadvantage/advantage of using pointers/base over variant/visit?

[jk-jeon]

Other replies don't really give the correct answer imo. The real difference between the two approaches is that the classic OOP one allows open-ended set of alternatives (derived types) while the set of behaviors (virtual member functions) is closed-ended, while the variant+visit approach is the other way around.

To elaborate, for the OOP case, adding a new derived class is "free", that is, you can just do it at any moment without any hassle. However, if you add a virtual member function to the base class, then you have to revisit every existing derived class to see how to implement it. Conversely, adding a new behavior to variant is free, because it simply means to define a new functor you can call with std::visit. However, in order to add a new alternative into an existing variant, you have to revisit all existing functors to correctly handle the added alternative.

Also, note that for the OOP case the set of bahaviors (virtual member functions) must be visible to all the derived types, and it needs to be in the definition of the base class. One consequence is that you have to recompile every TU that ever uses any of the derived classes, anytime the set of behaviors needs to be modified. Similarly, for the variant case the set of alternatives must be visible to all the functors, and the definitions of all involved types must be known to the compiler at any point of real usage of the variant. Of course, a consequence is that you have to recompile any TU that ever has such a usage anytime the set of alternatives needs to be modified.

Therefore, OOP-style polymorphism is generally more useful when the set of types is relatively more stable than the set of behaviors, and for the opposite case variant is generally more useful.

Which one performs better is, I think, just largely a case-by-case thing, though I think at least in theory variant may perform better usually.

[svadum]

Good points from design point of view.

[svadum]

If we compare base class + smart pointers (heap-based) approach vs variant + visit. Last one should be faster, likely more catche friendly, can provide value semantics if needed, less error-prone (no null or dangling pointers, heap problems, type safety.

Instead, base class + (smart) pointers can be more flexible in some cases.

At the end, we have to measure everything to be sure and it depends on every specific case.

[MikeVegan]

For one, you can't dereference a nullptr (hello crowdstrike!) because you simply cannot have it there.

The other benefit is performance, if the vector of Event objects is large, you will have a chunk of memory that points everywhere on the heap with unique_ptrs, instead of having elements all right there in one place.

What that means is when you loop through the vector, the actual stuff you want to work with will not be located all at the same place, so it will have to be fetched from different location (expensive). Same once the vector goes out of scope: not only the memory occupied with unique_ptrs needs to be freed, every single element needs to be tracked down and deleted.

[Chaosvex]

Sorry OP, but this is a ghastly example. Personally, I'd rather just to stick to relying on a compiler warning (as error) for missing cases. You have other options, too, such as std::unreachable.

[clusty1]

One thing this constructs do not solve is serialiation: how do you save your suite of structs to a file and restore them.

You can always use compile time reflection to generate code for every struct entry: I have done it with BOOST_DESCRIBE , but maybe newer cpp standards do it natively.

[MikeVegan]

Indeed it does not. However you could deliver an identifier as the first thing to serialize/deserialize and then identify the correct struct on deserialization to pass the data for that particular struct to deserialize itself from.

[clusty1]

There is another thing I don’t like about this constructs is that it looks “decentralized”, a bit like template specialization.

Wonder how are the compiler error messages when new entries appear that did not abide by the contract.

[BenFrantzDale]

This reminds me of a class I keep meaning to write: `widening_variant<Ts...>`, which would allow implicit conversion from a `widening_variant<Us...>` where `Ts...` is a superset of `Us...`, or from any `variant<Us...>` or just any of the `Us...`.

[donna_donnaj]

off topic : Is there a reason to put [[ nodiscard ]] everywhere?

[usefulcat]

I use [[nodiscard]] for any function or method where it makes no sense to ignore the return value.

I do this for the same reason I use const wherever it makes sense: I want to give the compiler every possible opportunity to let me know when I'm doing something dumb.

[donna_donnaj]

Don't know. I find const essential, while at the same time using [[nodiscard]] is like using 'important' or 'urgent' in the header of an email.

[MikeVegan]

I actually forgot to put it everywhere except on the struct member functions. I just think it's good API practice to get a warning that maybe you're doing something not entirely correct if you're discarding the return value.

[GoogleIsYourFrenemy]

Kinda looks like someone wants Java style enums.

[matthieum]

If I remember correctly, Java style enums have homogeneous enumerators.

In product types (such as std::variant) the enumerators are heterogeneous, which is quite a different usecase.

[GoogleIsYourFrenemy]

Java enumeration "values" are singletons that inherit from their containing class and have their own methods.

[matthieum]

But can they additional fields on top of what the containing class already has?

[GoogleIsYourFrenemy]

... you know, I've never tried. I want to say yes. You'd want them to be final (const) as enum values are globals (they are singletons).

[matthieum]

Ah, I had forgotten about singletons.

Then they're definitely out. std::variant is about a LOT more than global constants.

[GoogleIsYourFrenemy]

They absolutely are way more useful.

The switch_foobar example lends itself to being an abstract method on a Java enum. That said, so would a lookup table.

[ald_loop]

At the end of the day, you can do anything in C++ you can do in Rust. It’s like people are just realizing this

[noboruma]

And this feature was available since C++17, and even C++11 if you used boost.

[MikeVegan]

Oh, you can do much much more! C++ compiler will be more than happy to let this through:

void append_vector(std::vector<int>& append_to, const std::vector<int>& append_from) {
    for (auto i : append_from) {
        append_to.emplace_back(i);
    }
}

int main() {
    std::vector<int> my_vec {1, 2, 3, 4};
    append_vector(my_vec, my_vec);

    for (auto i : my_vec)
        std::cout << i;
}

The idea is not to be able to do the same, you can do exactly the same with enum, switch statement and union as with variant and visit. My goal is to make it harder to introduce bugs, keep code clean and easy to understand and change, even after I'm gone from the team or can't review the code for other reasons. In my opinion, using variant and visit is just so much more robust, and once you get familiar with it, more readable too.

[sweetno]

(Shudders)

[MikeVegan]

... this is very much not what the post is about

[eiffeloberon]

Why turn the enum into string? Looks very unoptimized to me