This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.
3352.strong_equality
isn't a thing
Section: 23.2.2 [container.requirements.general] Status: C++20 Submitter: Casey Carter Opened: 2019-12-06 Last modified: 2021-02-25
Priority: 1
View other active issues in [container.requirements.general].
View all other issues in [container.requirements.general].
View all issues with C++20 status.
Discussion:
[tab:container.req] includes the row:
Expression:
Return Type:i <=> j
strong_ordering
ifX::iterator
meets the random access iterator requirements, otherwisestrong_equality
. Complexity: constant
"strong_equality
" is (now) a meaningless term that appears nowhere else in the working draft. Presumably we want to make the Return Type unconditionally strong_ordering
, and require this expression to be valid only when i
and j
are random access iterators. It's not clear to me if the best way to do so would be to add a "Constraints" to the "Assertion/note/pre-/post-condition" column of this table row, or if we should pull the row out into yet another "conditionally-supported iterator requirements" table.
[2019-12-21 Issue Prioritization]
Priority to 1 after reflector discussion.
[2020-02-10, Prague; David Olsen provides new wording based upon Tim Songs suggestion]
[2020-02 Moved to Immediate on Tuesday in Prague.]
Proposed resolution:
Table 71 — Container requirements [tab:container.req] Expression Return type Operational
semantics Assertion/note
pre/post-condition Complexity[…]
i <=> j
strong_ordering
ifX::iterator
meets the
random access iterator
requirements, otherwisestrong_equality
Constraints:X::iterator
meets the random access iterator requirements. constant[…]
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