Title
A less hacky and more useful way to compare comparison category types
Status
new
Section
[cmp.categories]
Submitter
Corentin Jabot

Created on 2024-01-31.00:00:00 last changed 10 months ago

Messages

Date: 2024-02-04.11:27:52

Proposed resolution:

This wording is relative to N4971.

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

Date: 2024-01-31.00:00:00

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

History
Date User Action Args
2024-02-04 11:27:52adminsetmessages: + msg13943
2024-01-31 00:00:00admincreate