You need to separately default == as well.

a == b does not get rewritten to (a <=> b), though it can be rewritten to b
== a.

On Wed, Sep 27, 2023 at 19:45 Chris Gary via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> You've repeated yourself without thinking about what I wrote. You've
>> answered
>> for equality. Now think about the other operators: how does it implement
>> "is
>> less" for the type I proposed earlier? Mind you, it is strongly ordered
>> and
>> memcmp() only returns sign, not constraining itself to -1, 0, 1.
>
>
> What I've stated covers all cases of <=>. I keep repeating myself because
> I keep reading the same appeal to convention over and over again.
>
> The issues of composability that keep coming up are the same as the
> distinction in byte ordering. LE integers compose regardless of limb size,
> BE do not. For an LE thing made out of smaller BE things, value comparisons
> are needed and so on.
>
> Memberwise comparison is already implemented in exactly the same way as
> I've described.
> Its even in the documentation:
>
>> Defaulted three-way comparison
>>
>> The default operator<=> performs lexicographical comparison by
>> successively comparing the base (left-to-right depth-first) and then
>> non-static member (in declaration order) subobjects of T to compute <=>,
>> recursively expanding array members (in order of increasing subscript), and
>> stopping early when a not-equal result is found, that is:
>>
>
> https://godbolt.org/z/7xfKrKfTb
>
> The same as memberwise assignment, default construction, etc...
> Takes the least restrictive ordering, or partial_order.
> It looks like all things are in general partial_order, if that helps
> clarify again.
>
> saturate_to_tbl() -> {-1,0,1}|{-2}. You can call the members whatever
> you'd like. Everything not {a,b,c} is an error and maps to "explode",
> "idunno", or "hot_potato".
> I don't advise building general predicates on the de-facto definition of
> memcmp.
>
> I'm asking for a relaxation on the return type and the most general rules
> adopted in those cases.
>
> This is wrong-looking:
> https://godbolt.org/z/WjGExfxeW
>
> What does intuition suggest should happen? A well-defined operator ==,
> just like above.
> That doesn't exist here for some reason... Yet, with a default, it does.
> What happened?
> Composability issues? No, not with the default. But, when the user tries
> to define it... no reason given.
>
> This is very wrong-looking:
> https://godbolt.org/z/qabfh9WGT
>
> I can't use <=>, because I can't actually get it to synthesize a trivial
> '==' ... Compiler bug?
> How is this thing unrecoverably out in the wild when it isn't
> feature-complete? What did I miss?
>
> Different std::x_ordering can do nothing to guarantee anything to the
> compiler or reader, not any more than the assumptions I've just stated for
> an integral type.
> That an ordering can change dynamically is enough to realize the more
> general case has to be assumed.
> Optimization can take care of the special cases.
> Documentation makes those special cases clear, in context.
>
> On Wed, Sep 27, 2023 at 3:52 PM Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Wednesday, 27 September 2023 14:00:51 PDT Chris Gary via Std-Proposals
>> wrote:
>> > Type-safe composition of ordering can follow an intuitive definition.
>> >
>> > For two structures, compare each pair of members in the declaration
>> order,
>> > apply common_type<> and take the first result that is not equal. Where
>> one
>> > structure is longer than the other, let common_type<T,void> -> T, then
>> > invoke "T{} <=> value". Assuming plain bytes, the result is the same as
>> a
>> > memcmp with zero-padded arguments.
>>
>> You've repeated yourself without thinking about what I wrote. You've
>> answered
>> for equality. Now think about the other operators: how does it implement
>> "is
>> less" for the type I proposed earlier? Mind you, it is strongly ordered
>> and
>> memcmp() only returns sign, not constraining itself to -1, 0, 1.
>>
>> > While an enum is supposed to represent a contract and combine
>> accordingly,
>> > it really can't. Robust code has to have a path assuming that, like any
>> > other function, it can produce incorrect results, or a way to debug the
>> > thing. It can't guarantee that the ordering is implemented correctly,
>> and
>> > that we have this extra thing called "unordered" instead of
>> > "something_broke".
>>
>> Yeah, no. That's not how it works, not how it's implemented, how it's
>> designed
>> or how we should design.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DCAI Cloud Engineering
>>
>>
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>