It's probably more of use to compiler/runtime developers than end users if the language.
std::variant<int, whatever> v;
// v is zero std::variant<int, whatever> v = 0;
This. monostate's behavior should be captured in the std::optional spec. There's no need to create a new type.
Edit: My point, if not clear, is that the compiler should add the extra bit of code for when an optional is empty automatically, rather than requiring that an optional be defined (it's optional!) unless it is explicitly typed as monostate.
Brevity, I guess? I suppose the most brief way to express absence or presence of value in C++ is a pointer, but I could be tried at the Hague for that take.
None of this is to be facetious, I'm really trying to learn here. I'm not a C++ guy by trade. C and Rust are my day-to-day languages.
std::variant<std::monostate, T, U, V>
std::optional<std::variant<T, U, V>>
The other obvious use is what the article states, that it allows the variant to be default constructed even if none of its members are. Though you can do that with optional as well. It's mostly a matter of style. I mostly avoid std::monostate because the name is so confusing, I really agree with the other users that something like std::unit or std::none would be better.
Ah, okay! So it's serving the same purpose as the "None" in this Rust snippet:
enum Foo {
None, // <-- impl core::Default and return this
T(T),
U(U),
V(V),
}
Fundamentally, Rust’s enums are a much better way of doing this thing compared to std::variant, but C++ did the best it could without changing the core language. Which arguably they should have done.
The size of an optional<T> is `sizeof T + 1` because it needs a boolean for the set/unset flag.
The size of a variant is… the same, at least, because it needs to store a discriminator integer (apparently both gcc and clang do optimise to a byte when there are less than 256 variants).
Or do you mean adding a monostate to an existing variant rather than wrap that variant into an `optional`? In which case you should fix your example (and provide a version wrapped in an optional) because they’re very confusing.
Current situation: you have
std::variant<int, whatever> x;
// case 1
std::variant<int, whatever> x;
// case 2
std::variant<int, whatever> x = 0;
option A: does not needlessly increase sizeof, does not add indirection penalty upon access:
std::variant<std::monostate, int, whatever> x;
std::optional<std::variant<int, whatever>> x;