Issue 2885: The relational operators of optional and variant completely reflect the semantics of the element types — this is inconsistent with other types in the library

2885. The relational operators of `optional` and `variant` completely reflect the semantics of the element types — this is inconsistent with other types in the library

Section: 23 [containers], 22 [utilities] Status: LEWG Submitter: Finland Opened: 2017-02-03 Last modified: 2017-07-15

Priority: Not Prioritized

View other active issues in [containers].

View all other issues in [containers].

View all issues with LEWG status.

Discussion:

Addresses FI 17

The relational operators of optional and variant completely reflect the semantics of the element types; this is inconsistent with other types in the library, like pair, tuple and containers. If we believe it's important that we don't synthesize relational operators for wrapper types, we should believe it's important for other types as well. Otherwise comparing containers of floating-point types and tuples/pairs etc. of floating point types will give incorrect answers.

Proposed change: Make the relational operators of containers and utility components reflect the semantics of the operators for the underlying element types.

[2017-07 Toronto Thurs Issue Prioritization]

Move to LEWG

Proposed resolution:

2885. The relational operators of optional and variant completely reflect the semantics of the element types — this is inconsistent with other types in the library

2885. The relational operators of `optional` and `variant` completely reflect the semantics of the element types — this is inconsistent with other types in the library