Date: Sun, 13 Jun 2021 11:52:10 -0400
On Sun, Jun 13, 2021 at 5:39 AM Lénárd Szolnoki via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> I don't think we even need a common reference either. Is the common
> type commonly used by function templates requiring
> equality_comparable_with?
>
> I still think that there is a strong motivation for specifying "strong
> equality" between different types, but I don't think it requires any
> kind of common type. I think the following semantic requirements would
> do the trick:
>
> For t1. t2 of type T and u1, u2 of type U:
> * If `t1 == u1` and `t2 == u1` then t1 and t2 are substitutable.
> * If `u1 == t1` and `u2 == t1` then u1 and u2 are substitutable.
>
> Substitutable: http://eel.is/c++draft/cmp.categories#pre-4
>
> Maybe it makes sense to give a name to only one side of the requirement
> here too.
>
> Some previous discussion here:
> https://groups.google.com/a/isocpp.org/g/std-proposals/c/_dBzUrC7FDc/m/_Wj8tbpSBgAJ
I feel that the common-reference approach is based on a combination of
two ideas:
1. The meaning and behavior of comparing between two types is
something that needs to be carefully thought out by the user.
2. It's really easy to accidentally advertise equality_comparable_with
without fulfilling the semantic requirements of it.
It's not so much that you can't define equality_comparable_with mainly
through semantic constraints; it's that you shouldn't. That doing so
will encourage the creation of ad-hoc, semantic-less comparisons that
happen to fill the syntactic constraints without dealing with their
meaning.
So if you're dealing with someone who wants to follow the
common-reference scheme, I think it's important to attack one of these
two ideas. That is, the question is not whether it is *possible*, but
whether we *ought to*.
And understand: I agree that we ought to. But I think we need to
attack the arguments against it from the right perspective. I don't
feel this solution solves the problem that common-reference does, as
it imposes a purely semantic requirement. Your approach falls afoul of
#2, so we need a convincing argument why #2 is wrong.
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> I don't think we even need a common reference either. Is the common
> type commonly used by function templates requiring
> equality_comparable_with?
>
> I still think that there is a strong motivation for specifying "strong
> equality" between different types, but I don't think it requires any
> kind of common type. I think the following semantic requirements would
> do the trick:
>
> For t1. t2 of type T and u1, u2 of type U:
> * If `t1 == u1` and `t2 == u1` then t1 and t2 are substitutable.
> * If `u1 == t1` and `u2 == t1` then u1 and u2 are substitutable.
>
> Substitutable: http://eel.is/c++draft/cmp.categories#pre-4
>
> Maybe it makes sense to give a name to only one side of the requirement
> here too.
>
> Some previous discussion here:
> https://groups.google.com/a/isocpp.org/g/std-proposals/c/_dBzUrC7FDc/m/_Wj8tbpSBgAJ
I feel that the common-reference approach is based on a combination of
two ideas:
1. The meaning and behavior of comparing between two types is
something that needs to be carefully thought out by the user.
2. It's really easy to accidentally advertise equality_comparable_with
without fulfilling the semantic requirements of it.
It's not so much that you can't define equality_comparable_with mainly
through semantic constraints; it's that you shouldn't. That doing so
will encourage the creation of ad-hoc, semantic-less comparisons that
happen to fill the syntactic constraints without dealing with their
meaning.
So if you're dealing with someone who wants to follow the
common-reference scheme, I think it's important to attack one of these
two ideas. That is, the question is not whether it is *possible*, but
whether we *ought to*.
And understand: I agree that we ought to. But I think we need to
attack the arguments against it from the right perspective. I don't
feel this solution solves the problem that common-reference does, as
it imposes a purely semantic requirement. Your approach falls afoul of
#2, so we need a convincing argument why #2 is wrong.
Received on 2021-06-13 10:52:25