Title
strong_equality isn't a thing
Status
c++20
Section
[container.requirements.general]
Submitter
Casey Carter

Created on 2019-12-06.00:00:00 last changed 46 months ago

Messages

Date: 2020-02-12.03:28:55

Proposed resolution:

Table 71 — Container requirements [tab:container.req]
Expression Return type Operational
semantics
Assertion/note
pre/post-condition
Complexity
[…]
i <=> j strong_ordering if
X::iterator meets the
random access iterator
requirements, otherwise
strong_equality
Constraints: X::iterator meets the random access iterator requirements. constant
[…]
Date: 2020-02-12.03:28:55

[ 2020-02 Moved to Immediate on Tuesday in Prague. ]

Date: 2020-02-15.00:00:00

[ 2020-02-10, Prague; David Olsen provides new wording based upon Tim Songs suggestion ]

Date: 2019-12-21.00:00:00

[ 2019-12-21 Issue Prioritization ]

Priority to 1 after reflector discussion.

Date: 2019-12-06.00:00:00

[tab:container.req] includes the row:

Expression: i <=> j

Return Type: strong_ordering if X::iterator meets the random access iterator requirements, otherwise strong_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.

History
Date User Action Args
2021-02-25 10:48:01adminsetstatus: wp -> c++20
2020-02-24 16:02:59adminsetstatus: immediate -> wp
2020-02-12 03:28:55adminsetmessages: + msg11041
2020-02-12 03:28:55adminsetstatus: new -> immediate
2020-02-10 19:18:57adminsetmessages: + msg11030
2020-02-10 19:18:57adminsetmessages: + msg11029
2019-12-21 14:17:03adminsetmessages: + msg10897
2019-12-06 00:00:00admincreate