There is a difference between "incomparable" and "unordered" because
incomparable doesn't imply induced equivalence classes. Partial order gives
you unordered.

You get "unordered" relationships in lattices, and you get "incomparable"
with NaNs or disjoint unions on lattices where the order between sections
is not defined.

It's nice to be able to just synthesize these things when you're dealing
with graph products, where you have partially ordered subgraphs but you
don't want to induce an order on the points between layers.

Ints do not have enough semantics to tell you what can and cannot happen in
your generic algorithms, and for graphs you really need those.

I think the design we passed is sufficiently simplified to be useful, yet
expressive enough for most computational use-cases that interop between
libraries would need.

Ints aren't composable between domains.

On Thu, Sep 28, 2023, 08: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
>