>
> 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
>