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

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