This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

4051. A less hacky and more useful way to compare comparison category types

Section: 17.12.2 [cmp.categories] Status: New Submitter: Corentin Jabot Opened: 2024-01-31 Last modified: 2025-10-23

Priority: 3

View all other issues in [cmp.categories].

View all issues with New status.

Discussion:

Comparison categories can only be compared to the literal 0. It does not make sense for them to be comparable to anything else, so conceptually, the design of P0515 makes sense, however in practice it's a pain point from users and implementations alike, as the desired semantics is barely implementable.

• One implementation strategy is to use nullptr_t. This produces warnings in implementations because using a 0 pointer constant is not recommended, and filtering out these warnings would be unreliable.

• Another implementation strategy is to require a consteval expression but

  • This permits 1-1, which ought to be totally fine and yet it exposes users to UB

  • It is not SFINAE friendly (and attempts at SFINAE are presumably UB).

And there are use cases where SFINAE friendliness is important, notably testing frameworks.

The status quo has engendered multiple issues being reported to at least 3 vendors

Suggestion:

• Allow any 0 constant expression

• Require compile magic to SFINAE on non zero values

• Remove the gratuitous UB

The proposed wording requires compiler magic and has been implemented in clang. (Other possible way to implement that would for example be a magic type attribute, or a magic type)

Related vendor issues:

GCC Bugzilla issue 96278

GCC Bugzilla issue 100903

LLVM issue 43670

LLVM pulls request 79465

Microsoft STL issue 4359

Microsoft STL pull request 3581

Visual Studio issue 10509214

snitch issue 140

[2025-10-23; Reflector poll.]

Set priority to 3 after reflector poll.

We should prefer rejecting the undefined expression at compile time, rather than leading to UB at runtime.

There is implementation divergence for SFINAE checks between the standard library implementations. The has_a_value(std::strong_ordering::equal) is false for libstdc++, and true for libc++, MSVC:

auto has_a_value(const auto& t) {
  if constexpr (requires { t.has_value(); }) {
    return t.has_value();
  } else if (constexpr (requires { t != nullptr; }) {
    return t != nullptr;
  } else {
    return true;
  }
}

Proposed resolution:

This wording is relative to N4971.

1. Modify 17.12.2.1 [cmp.categories.pre] as indicated:

   -3- The relational and equality operators for the comparison category types are specified with an anonymous parameter of unspecified type. This type shall be selected by the implementation such that these parameters can only accept an integral constant expression evaluating toliteral 0 as a corresponding argument.

   [Example 1: nullptr_t meets this requirement. — end example]

   In this context, the behavior of a program that supplies an argument other than a literal 0 is undefined.