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 typesSection: 17.12.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.
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 140Proposed resolution:
This wording is relative to N4971.
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 to literal
[Example 1:0as a corresponding argument.nullptr_tmeets this requirement. — end example] In this context, the behavior of a program that supplies an argument other than a literal0is undefined.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4