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]
> <http:///compose?To=ecatmur_at_[hidden]>> wrote:
>
> > On Mon, 19 Dec 2022 at 21:09, Lénárd Szolnoki <cpp_at_[hidden]
> <http:///compose?To=cpp_at_[hidden]>>
> > wrote:
> >
> > >
> > >
> > > On 19 December 2022 19:05:33 GMT, Edward Catmur
> > > <ecatmur_at_[hidden] <http:///compose?To=ecatmur_at_[hidden]>>
> wrote:
> > > >On Mon, 19 Dec 2022 at 19:05, Lénárd Szolnoki
> > > ><cpp_at_[hidden] <http:///compose?To=cpp_at_[hidden]>>
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> On 19 December 2022 17:10:18 GMT, Edward Catmur
> > > >> <ecatmur_at_[hidden] <http:///compose?To=ecatmur_at_[hidden]>
> > > >
> > > >> wrote:
> > > >> >On Mon, 19 Dec 2022 at 17:56, Lénárd Szolnoki via
> > > >> >Std-Discussion < std-discussion_at_[hidden]
> <http:///compose?To=std%2ddiscussion_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]
> <http:///compose?To=Std%2dDiscussion_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
>