C++ Logo

std-discussion

Advanced search

Re: Comparison operators

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Tue, 20 Dec 2022 21:19:02 +0000
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

Received on 2022-12-20 21:19:09