为什么 C++20 中的空结构没有隐式宇宙飞船运算符？

Question

Motivation: sometimes I use std::variant to implement "fancy" enum where some enum states can carry state.

Now if I want to use the <=> for my variant it requires that my empty structs have defined <=>. That seems a bit weird to me since if type has 0 bits of state all instances of that type are same.

Full example :

#include <compare>
#include <iostream>
#include <variant>

struct Off{
    // without this the code does not compile
    auto operator<=>(const Off& other) const = default;
};

struct Running{
    int rpm=1000;
    auto operator<=>(const Running& other) const = default;
};

using EngineState = std::variant<Off, Running>;

int main()
{
    EngineState es1, es2;
    es1<=>es2;
}

Answer 1

The defaulted comparison operator is opt-in, not opt-out.

If it was opt-out, then it could turn code that would not compile into code that compiles with some unknown meaning. The standard committee tries to maintain backwards compatibility as much as possible.

Answer 2

The reason for this ultimately comes down to this: what does it mean for a type to be "comparable"?

A type that is comparable is, first and foremost, a type which carries a value . Objects of such types carry a value that is meaningful in some sense.

Your example is one such case. Essentially, you are using variant and Off to augment the value-state of Running with an alternative value. I would have used optional<Running> myself, but whatever. Off is a type which legitimately has a value within your problem space. Its value being "not running".

This is not the case for most empty object types. std::in_place_t has no meaningful "value" by any definition of that term. It's a tag used to dispatch in-place construction calls to constructors of certain types. Asking to compare one instance to another makes no sense.

Yet you want to make it comparable by default.

There are a lot of stateless types that are not used in a value-oriented way. Tags for dispatching to overload sets, types used to provide object-based access to global resources, etc. That's not to say that there are no value-oriented empty types. But there are enough of them that unilaterally declaring that all of them ought to be comparable by default seems very strange.

Also, being value-oriented is a necessary condition for comparability, but it is not alone sufficient . We don't have default comparability for types that are clearly value-oriented.

Aggregate types have all public members, so there's nothing stopping anyone from shoving any value in them at any time. They are clearly value-oriented.

Yet aggregate types are not comparable by default. Nor should they be. Not everything which could hypothetically be compared should be compared.

Even if a particular collection of values could be ordered, does it make sense to permit them to be ordered? That depends on the collection. If I have a 2D point type, it could be ordered. But should it? I can understand equality testing, but full-on comparability? You can define it, but is such a comparison ever meaningful ?

That's a question only the creator of the type can answer. Therefore, we force the creator of types to ask for what they want.

And having no members is just a special case of having some public members.