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?


> Cheers,
> Lénárd
>