inbal2l
commented
3 years ago The paper was reviewed on LEWG mailing list on 2021-09-13. (D1 with a fix was sent in the mail thread)
Summary
-
Issue: this is a breaking change. (some suggestions to consider as a DR to C++20) It's an incremental improvement over the status quo, the breakage cases are more theoretical than real. Outcome: It's agreed that the number of breakages is probably low. There were requests for adding a survey to the paper.
-
Issue: concerns regarding increasing subsumption algorithm's complexity Suggestion to eliminate the disjunction and instead introduce an atomic constraint for (convertible_to<const T&, common_reference_t<...>> || convertible_to<T&&, common_reference_t<...>>) Author: Agreed. I'll revise the paper with that. (fixed at D1)
-
Issue: the change might not be worth our time, since it comes up only in edge case Some suggest it's not an edge case (for example: unique_ptr).
-
Issue: it's not true that the common supertype conversion never needs to happen at runtime Some designs require monomorphic functions. Relaxing the requirement that the conversion actually exists and can be called at runtime will break anybody using monomorphic callbacks with proxy iterators.
Additional comments on the topic
- There's a discussion on whether we should weaken the requirements (to achieve more "accurate" heuristic).
Few alternative suggestions (should be proposed on a separate paper):
- Introduce new customization point, trait as follows: bool enable_three_way_comparable_with, bool enable_equality_comparable_with Then replace the requirements on common_reference_t (existence and meeting concept) with just checking for the corresponding enable.
- Add a separate weakly_equality_comparable_with, partially_ordered_with Regarding equality_comparable_with - most people assume it should work with any two objects which are able to use the operator = between them. That is not the case, and the cases for which there are common references don't seem to be the main cases for which this concept would be useful. The types for which weakly_equality_comparable_with is most useful for are those types which have inconsistent operator==(T, U) and operator==(T, T) / operator==(U, U). In this case, the operator==(T, U) can actually be an equality (form an equivalence relation), but this equality is not consistent with operator==(T, T) or operator==(U, U); iterator/sentinel operator== is actually a case of this.
- Not use common_reference_t, but instead use an alternative which can fall back on common_comparison_type_t or to_common_comparison(T, U)
- Heterogeneous comparison comes up as a topic (additional related comments on the thread: "LEWG(I) Weekly review - P2405R0: nullopt_t and nullptr_t should both have operator and operator==")
- Relevant proposals:
- P0805: Comparing Containers.
- N3351 (search term: "equational").
Outcome
The proposal generally got good support for fixing / addressing the issue. Relaxing concepts' requirements and the proposed alternatives were subject to a discussion. Since it is a breaking change (and potential C++20 DR) it should be discussed in LEWG telecon.
brycelelbach
wg21bot
cor3ntin
jwakely
JeffGarland
P2404R0 Relaxing equality_comparable_with's and three_way_comparable_with's common reference requirements to (Justin Bassett)