Why isn't std::variant allowed to equal compare with one of its alternative types?

Question

For example, it should be very helpful to equal compare a std::variant<T1, T2> with a T1 or T2. So far we can only compare with the same variant type.

I think c++20 just added it to the draft with the [mothership proposal](https://brevzin.github.io/cpp_proposals/118x_spaceship/p1614r0.html#was-ill-formed-now-well-formed) — Guillaume Racicot, Mar 20 '19 at 18:36
@GuillaumeRacicot In that same link, I believe it's saying the int would be implicitly cast to `std::variant` to satisfy the comparison function signature. For an int, that's probably trivial. But for a string, that could mean a copy. — Cruz Jean, Mar 20 '19 at 18:43
Shouldn't the compare also work in C++17? the operator== is a freestanding function. And variant has a non-explicit conversion-constructor, so variant() == T1() should convert T1 to variant and it shuould find the freestanding operator==. Actually after a check I found out that it does not work. Why is that so? — Kilian, Mar 21 '19 at 22:24
Actually following code works: struct X { template X(T&&) {} }; bool operator==(X const&, X const&); X x(10); bool b = x==10; So it seemes to be related to operator== being a template. — Kilian, Mar 21 '19 at 22:25

score 11 · Answer 1 · answered Mar 20 '19 at 18:25

11

A variant may have multiple duplicates of the same type. E.g. std::variant<int, int>.

A given instance of std::variant compares equal to another if and only if they hold the same variant alternative and said alternatives' values compare equal.

Thus, a std::variant<int, int> with index() 0 compares not equal to a std::variant<int, int> with index() 1, despite the active variant alternatives being of the same type and same value.

Because of this, a generic "compare to T" was not implemented by the standard. However, you are free to design your own overload of the comparison operators using the other helper utilities in the <variant> header (e.g. std::holds_alternative and std::get<T>).

answered Mar 20 '19 at 18:25

Cruz Jean

2,761
12
16

This is not an answer to the question, it's just a statement of the situation. You did not say _why_ "a given instance of std::variant compares equal to another if and only if etc. etc." – einpoklum Mar 20 '19 at 18:31
2

When comparing an `int` with `std::variant` it could compare the _active_ member with that `int`. – Maxim Egorushkin Mar 20 '19 at 18:32
@einpoklum The standard just decided it should be that way. I'm explaining the reason (in terms of how the comparison operators work in the standard) for why a generic comparison to `T` is not in the standard. – Cruz Jean Mar 20 '19 at 18:34
@MaximEgorushkin You may want it to be like that, but that's not what the standard decided. – Cruz Jean Mar 20 '19 at 18:35
@CruzJean Well, in variant visitor you cannot distinguish between the two now - the comparison can be just as oblivious. I am not sure what use case the standard had in mind, however, one can wrap an integer into a unique class and get more mileage out of that. – Maxim Egorushkin Mar 20 '19 at 20:24
A bit off-topic, but the standard libraries get outdated by the time they are integrated into the standard and then just code rot in there because standard library updates are almost non-existent. IMO, the standard commitee had better focus on modules, build and packaging system, so that people can pick and match libraries as they please. – Maxim Egorushkin Mar 20 '19 at 20:29
`boost::variant` has been available for decades, excluding _i can't use boost_ people. Integrating `boost::variant` into `std` wouldn't be necessary if C++ had a package repository and a build system. Brain dump completed. – Maxim Egorushkin Mar 20 '19 at 20:32
1

@MaximEgorushkin `boost::variant` also does not support equality-comparison with one of the alternative types. – Barry Mar 20 '19 at 21:03
@Barry True, i am not claiming otherwise. May be you could shed some light why variant supports duplicate types. Because if it didn't one could just do `myvariant == static_cast(myint)` to compare. What was the more useful use case to allow duplicate types? – Maxim Egorushkin Mar 20 '19 at 21:09
@MaximEgorushkin Because it's useful to model two different states that nevertheless have the same type. – Barry Mar 20 '19 at 21:15
@Barry One can always make 2 unique types from 1 type with a wrapper. IMO, that reason is not good enough. – Maxim Egorushkin Mar 20 '19 at 21:20
1

@MaximEgorushkin Because `variant` *always has* alternative 1 being `b`, and if alternative of var1 is not alternative of var2 they are never equal. If you go down the path of "well, I'm sure they meant `variant` when they said `variant`", you end up with javascript `"1"==1` insanity. If you want to go further, look up "sum types" in type theory. – Yakk - Adam Nevraumont Mar 21 '19 at 00:10
@Yakk-AdamNevraumont Could not understand your logic, sorry. – Maxim Egorushkin Mar 21 '19 at 09:57
What about an operator== between variant and T which only participates in overload resolution if T is one of the alternative types and the alternative types in the variant are unique? – Kilian Mar 21 '19 at 22:36
@Kilian I like that, and that's personally how I'd have done it - nice and easy impl too. Just needs an `index()` check plus a template visitor. The `index()` check just being to make sure `std::variant` holding `A` which is comparable to `B` still fails (so as not to fly in the face of the default comparison of two variants). – Cruz Jean Mar 23 '19 at 00:46

Ted Lyngmo · Answer 2 · 2023-02-20T11:19:59.640

I can't answer the why part of the question but since you think it would be useful to be able to compare a std::variant<T1, T2> with a T1 or T2, perhaps this can help:

template<typename T, class... Types>
inline bool operator==(const T& t, const std::variant<Types...>& v) {
    const T* c = std::get_if<T>(&v);

    return c && *c == t; // true if v contains a T that compares equal to t
}

template<typename T, class... Types>
inline bool operator==(const std::variant<Types...>& v, const T& t) {
    return t == v;
}

score 4 · Accepted Answer · answered Mar 20 '19 at 18:45

It is an arbitrary decision by the standards committee.

Ok, not quite arbitrary. The point is you have a scale^* of strictness of comparison, with points such as:

Most-strict: Only variants can equal each other, and they need to match both in the sequence-of-alternatives (i.e. the type), the actual alternative (the index, really, since you can have multiple identical-type alternatives) and in value.
Less-Strict: Equality of both the variant alternative, as a type and the value, but not of the sequence-of-alternatives, nor the index within that sequence (so the same value within two distinct alternatives of the same type would be equal).
Most-relaxed: Equality of the value in the active alternative, with implicit conversion of one of the elements if relevant.

These are all valid choices. the C++ committee made the decision based on all sorts of extrinsic criteria. Try looking up the std::variant proposal, as perhaps it says what these criteria are.

_{(*) - A lattice actually.}

Why isn't std::variant allowed to equal compare with one of its alternative types?

3 Answers3