Confusion on the spaceship operator in C++20

C++20 introduces the Spaceship Operator (<=>) in P0515R3. For those who are unfamiliar with three-way comparison, the spaceship operator tests whether x < y, x = y, or x > y. As such, the _expression_

if (x <=> 1000)

is equivalent to

if (x < 1000 || x == 1000 || x > 1000)

. However, I don't see the point of this kind of comparison. Logic suggests that such a comparison will always be true, unless comparing floating-point representations (though such a representation is always imprecise). So can someone explain when exactly such an operator would actually be useful? The paper states the following, though it doesn't actually help me understand exactly how this kind of comparison operator would be useful:

The primary design goal is conceptual integrity [Brooks 1975], which means that the design is coherent and reliably does what the user expects it to do. Conceptual integrity’s major supporting principles are:

  • Be consistent: Don’t make similar things different, including in spelling, behavior, or capability. Don’t make different things appear similar when they have different behavior or capability. – For example, this paper follows the principle that by default a=b implies a==b, so that after copying a value, we can assert equality. Also, all types can get all the comparison operators they want by uniformly writing the same function, the three-way comparison operator <=>, and express the kind of comparison they support by the returned comparison category type (e.g., returning strong_ordering vs. weak_ordering).

  • Be orthogonal: Avoid arbitrary coupling. Let features be used freely in combination. – For example, in this paper a type’s comparison category is expressed orthogonally to the operators, by specifying a different category by just selecting a different return type on the same operator function. Especially, it makes all previously controversial design points into independent options that can later be proposed as pure extensions to this design and that do not affect this core proposal (see revision R0 of this proposal for treatment of the optional parts that did not receive support in EWG+LEWG Kona 2017)).

  • Be general: Don’t restrict what is inherent. Don’t arbitrarily restrict a complete set of uses. Avoid special cases and partial features. – For example, this paper supports all seven comparison operators and operations, including adding three-way comparison via <=>. It also supports all five major comparison categories, including partial orders.

These also help satisfy the principles of least surprise and of including only what is essential, and result in features that are additive and so directly minimize concept count (and therefore also redundancy and clutter).



-- 
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
  • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Aminiel via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Aminiel via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : camlorn via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector
    • ... AudioGames . net Forum — Developers room : Ethin via Audiogames-reflector

Reply via email to