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.11.2 [cmp.categories] Status: New Submitter: Corentin Jabot Opened: 2024-01-31 Last modified: 2024-02-04

Priority: Not Prioritized

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.

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:

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

Proposed resolution:

This wording is relative to N4971.

  1. Modify 17.11.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.