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?
 
Cheers,
Lénárd