I saw these parts of the Standard.
 
Nevertheless the first reference does not make clear what is the difference between the «synthesized three-way comparison» operator function and just the three-wat comparison operator function. And in fact it does not provide the definition of the term «synthesized three-way comparison».
 
As for the second reference than it says nothing about for example non-static members of reference types. Whether in this case a relational operator is deleted or not.
 
With best regards
(Vlad from Moscow)
 
 
You can meet me at http://cpp.forum24.ru/ or www.stackoverflow.com or http://ru.stackoverflow.com
 
  
>Четверг, 22 декабря 2022, 19:42 +03:00 от Edward Catmur <ecatmur_at_[hidden]>:
>
>
>On Thu, 22 Dec 2022 at 12:44, Vladimir Grigoriev < vlad.moscow_at_[hidden] > wrote:
>>Hi, everybody.
>>
>>I’m sorry. It was my mistake. I read the phrase too quickly without taking into account its details.
>>
>>But I have some more question.
>>
>>The first one is where is there in the C++ Standard the definition of the term «synthesized three-way comparison»? What is the difference between the «synthesized three-way comparison» and the «three-way comparison»?
>
>http://eel.is/c++draft/class.spaceship#def:three-way_comparison,synthesized
>It's even in the index!
>
>>Another question is relative to this phrase
>>
>>«2 A defaulted <=> or == operator function for class C is defined as deleted if any non-static data member of C is of reference type or C has variant members (11.5.2).»
>>
>>Why are not relational operator functions mentioned in this phrase as deleted in this case?
>
>They are mentioned below. http://eel.is/c++draft/class.compare#secondary-2.sentence-1
>
>>With best regards,
>>(Vlad from Moscow)
>>
>>You can meet me at http://cpp.forum24.ru/ or www.stackoverflow.com or http://ru.stackoverflow.com
>>
>>
>>>Среда, 21 декабря 2022, 0:19 +03:00 от Lénárd Szolnoki via Std-Discussion < std-discussion_at_[hidden] >:
>>>
>>>On Mon, 19 Dec 2022 21:22:37 +0100
>>>Edward Catmur < ecatmur_at_[hidden] > wrote:
>>>
>>>> On Mon, 19 Dec 2022 at 21:09, Lénárd Szolnoki < cpp_at_[hidden] >
>>>> wrote:
>>>>
>>>> >
>>>> >
>>>> > On 19 December 2022 19:05:33 GMT, Edward Catmur
>>>> > < ecatmur_at_[hidden] > wrote:
>>>> > >On Mon, 19 Dec 2022 at 19:05, Lénárd Szolnoki
>>>> > >< cpp_at_[hidden] > wrote:
>>>> > >
>>>> > >> Hi,
>>>> > >>
>>>> > >> On 19 December 2022 17:10:18 GMT, Edward Catmur
>>>> > >> < ecatmur_at_[hidden]
>>>> > >
>>>> > >> wrote:
>>>> > >> >On Mon, 19 Dec 2022 at 17:56, Lénárd Szolnoki via
>>>> > >> >Std-Discussion < std-discussion_at_[hidden] > wrote:
>>>> > >> >
>>>> > >> >> My reading in pseudocode it would look something like:
>>>> > >> >>
>>>> > >> >> /* ...comparing corresponding elements xi and yi in the
>>>> > >> >> expanded
>>>> > lists
>>>> > >> of
>>>> > >> >> subobjects for x and y (in increasing index order) until the
>>>> > >> >> first
>>>> > >> index i
>>>> > >> >> where xi == yi yields a result value which, when contextually
>>>> > >> >>
>>>> > converted
>>>> > >> to
>>>> > >> >> bool, yields false. */
>>>> > >> >> bool mismatch_found = false;
>>>> > >> >> for (size_t idx=0; idx < member_count; ++idx) {
>>>> > >> >> if (not (lhs_members[idx] == rhs_members[idx]) {
>>>> > >> >> mismatch_found = true;
>>>> > >> >> break;
>>>> > >> >> }
>>>> > >> >> }
>>>> > >> >>
>>>> > >> >> // If no such index exists, ...
>>>> > >> >> if (not mismatch_found) {
>>>> > >> >> return true; // ... V is true.
>>>> > >> >> } else { // Otherwise, ...
>>>> > >> >> return false; // ... V is false.
>>>> > >> >> }
>>>> > >> >>
>>>> > >> >> The first part describes the side effects of the defaulted
>>>> > definition,
>>>> > >> and
>>>> > >> >> the short-circuiting in particular. The second part describes
>>>> > >> >> the
>>>> > >> returned
>>>> > >> >> value.
>>>> > >> >>
>>>> > >> >> Obviously this can be written more clearly and concisely in
>>>> > pseudocode.
>>>> > >> >> Would be nice if it could similarly be simplified in English.
>>>> > >> >>
>>>> > >> >
>>>> > >> >Close, but `not` doesn't necessarily do what it should. I'd say
>>>> > >> >this
>>>> > would
>>>> > >> >be more correct and idiomatic:
>>>> > >>
>>>> > >> Yes, you are right. At first I wanted to write !=, but then I
>>>> > "corrected"
>>>> > >> myself... It's pseudocode :)
>>>> > >>
>>>> > >> >/* ...comparing corresponding elements xi and yi in the
>>>> > >> >expanded lists
>>>> > of
>>>> > >> >subobjects for x and y (in increasing index order) until the
>>>> > >> >first
>>>> > index i
>>>> > >> >where xi == yi yields a result value which, when contextually
>>>> > converted to
>>>> > >> >bool, yields false. */
>>>> > >> >size_t idx=0;
>>>> > >> >for (; idx != member_count; ++idx) {
>>>> > >> > if (lhs_members[idx] == rhs_members[idx]) {
>>>> > >> > ;
>>>> > >> > } else {
>>>> > >> > break;
>>>> > >> > }
>>>> > >> >}
>>>> > >> >
>>>> > >> >// If no such index exists, ...
>>>> > >> >if (idx == member_count) {
>>>> > >> > return true; // ... V is true.
>>>> > >> >} else { // Otherwise, ...
>>>> > >> > return false; // ... V is false.
>>>> > >> >}
>>>> > >>
>>>> > >> I wonder if the English wording would be clearer if the if-else
>>>> > >> would be switched around.
>>>> > >>
>>>> > >> The current wording reads like:
>>>> > >>
>>>> > >> if (no such index exists) {
>>>> > >> V is true
>>>> > >> } else {
>>>> > >> V is false
>>>> > >> }
>>>> > >>
>>>> > >> I try to avoid if(!cond)...else in code, as now the else branch
>>>> > >> has a double negative.
>>>> > >>
>>>> > >> Replacing the last part of the wording with this might be
>>>> > >> clearer:
>>>> > >>
>>>> > >> "If such index exists, V is false. Otherwise V is true."
>>>> > >>
>>>> > >
>>>> > >I think part of the reason for the current wording is that it
>>>> > >parallels that for spaceship, where the double negative does make
>>>> > >sense: https://eel.is/c++draft/class.compare#class.spaceship-3
>>>> >
>>>> > This would be a good point, if the wording here actually mirrored
>>>> > [class.eq], but it does not. Here the value for the "no such
>>>> > index" case is described later to the short-circuit case. An
>>>> > equivalent [class.eq] wording would be the following:
>>>> >
>>>> > The return value V of a defaulted == operator function with
>>>> > parameters x and y is determined by comparing corresponding
>>>> > elements xi and yi in the expanded lists of subobjects for x and y
>>>> > (in increasing index order) until the first index i where xi == yi
>>>> > yields a result value which, when contextually converted to bool,
>>>> > yields false; V is false. If no such index exists, V is true.
>>>> >
>>>>
>>>> You're completely correct; I was looking at the overall form (and the
>>>> last sentence). And that "equivalent" wording is, if a bit clumsy,
>>>> still more unambiguously readable that what we have today.
>>>>
>>>> >>Of course in real code I would just return from the loop on
>>>> >>mismatch, but
>>>> > I
>>>> > >> don't know how to convey that in English.
>>>> > >>
>>>> > >
>>>> > >It's tricky; English (and in particular Standardese) isn't really
>>>> > >lent to conveying that kind of algorithm. Quite honestly I don't
>>>> > >feel that there's much need to improve the wording; most people
>>>> > >who read the specification itself will know how to write a
>>>> > >short-circuiting equality operator anyway, so need only check that
>>>> > >the wording can be read with that in mind.
>>>> >
>>>> > It's of course subjective. I agree that the current wording is
>>>> > unambiguous, but I also needed to read it a couple of times to
>>>> > parse the last "otherwise". And apparently several other people
>>>> > also had trouble with it.
>>>> >
>>>> > It's probably a very minor thing to nitpick about, but it might
>>>> > worth an editorial change.
>>>> >
>>>>
>>>> Yes, editorial should do it. Do you want to enter a PR?
>>>I raised https://github.com/cplusplus/draft/issues/6036 .
>>>
>>>I didn't want to commit to one particular wording, so no PR.
>>>
>>>Cheers,
>>>Lénárd
>>>
>>>--
>>>Std-Discussion mailing list
>>>Std-Discussion_at_[hidden]
>>>https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>