On Thu, 22 Dec 2022 at 20:47, Vladimir Grigoriev <vlad.moscow@mail.ru> wrote:
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.

It also doesn't make clear the difference between a raven and a writing-desk. That's not the purpose of the Standard.

A three way comparison operator expression [expr.spaceship] may, when evaluated, invoke an overloaded three-way comparison operator [over.oper.general]. This may be a defaulted three-way comparison operator function [class.compare.default]. If so, this is defined in terms of synthesized three-way comparison [class.spaceship].

And in fact it does not provide the definition of the term «synthesized three-way comparison».

As Jason says, it *is* the definition.

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.

http://eel.is/c++draft/class.compare#default-2

With best regards
(Vlad from Moscow)
 
 
 
 
Четверг, 22 декабря 2022, 19:42 +03:00 от Edward Catmur <ecatmur@googlemail.com>:
 
 
 
On Thu, 22 Dec 2022 at 12:44, Vladimir Grigoriev <vlad.moscow@mail.ru> 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»?
 
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? 
 
 
With best regards,
(Vlad from Moscow) 
 
 
 
Среда, 21 декабря 2022, 0:19 +03:00 от Lénárd Szolnoki via Std-Discussion <std-discussion@lists.isocpp.org>:
 
On Mon, 19 Dec 2022 21:22:37 +0100
Edward Catmur <ecatmur@googlemail.com> wrote:
 
> On Mon, 19 Dec 2022 at 21:09, Lénárd Szolnoki <cpp@lenardszolnoki.com>
> wrote:
>
> >
> >
> > On 19 December 2022 19:05:33 GMT, Edward Catmur
> > <ecatmur@googlemail.com> wrote:
> > >On Mon, 19 Dec 2022 at 19:05, Lénárd Szolnoki
> > ><cpp@lenardszolnoki.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> On 19 December 2022 17:10:18 GMT, Edward Catmur
> > >> <ecatmur@googlemail.com
> > >
> > >> wrote:
> > >> >On Mon, 19 Dec 2022 at 17:56, Lénárd Szolnoki via
> > >> >Std-Discussion < std-discussion@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion