On Wed, Sep 27, 2023 at 9:29 PM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> Though it's interesting that you're suddenly OK with including a
>> header for your `std::saturate_to_tbl` function. You *are* proposing
>> adding such a function to the standard library, right? Because your
>> proposal is incomplete without it, as it would be unable to interact
>> with C convention-based code. Unlike the status quo, where all you
>> have to do is apply `<=> 0`.
>
>
> I kept saying the likes of "saturate_to_tbl" are supposed to be compiler-generated code.

What syntax would cause the compiler to generate that code?

> What is the equivalent of:
>
> auto operator <=> ( const Example &other ) const noexcept
> { return this->value <=> other.value; }
>
> and not having to resort to writing any of the other 6?

There is none. Neither `==` nor `!=` will *ever* call `operator<=>`.
Defaulting `<=>` also defaults `==`, but that's the only time
`operator<=>` has any effect on `operator==`.

But this is off-topic, as this behavior has absolutely nothing to do
with what `operator<=>` returns. The reason for this separation is
just as valid whether the function returned an `int`. The reasoning is
laid out in P1185
(https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1185r0.html)
and that reasoning has nothing at all to do with the return type of
`operator<=>`.

> This works as it reads:
> https://godbolt.org/z/7xfKrKfTb
>
> This is confusing:
> https://godbolt.org/z/WjGExfxeW
>
> This is very confusing (re-done to use partial_ordering, not that it matters):
> https://godbolt.org/z/1xfcjacse
>
> Even the documentation states "object that can be compared against 0". Before I suggested the interval saturation, that is what I was expecting. Someone brought up NaNs, so the table-lookup was just another exposition of making that odd idea work.
>
> Are you expecting a thing to behave a certain way in a container? Write a predicate for the container.

That's absurd. The point of the semantics of comparisons is so that it
behaves a certain way *by default*.

> Trying to convey the ordering category of a type? There are static solutions (a return type), and there are dynamic solutions.
> An enum here doesn't help where the category may change dynamically.

The category changing dynamically (at runtime) makes absolutely no
sense. The meaning of a comparison is not part of the value of an
object.