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

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.

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.
So, what I've tried to do is just use std::partial_ordering, and cope. As
demonstrated above, that can't happen in a simple way apparently.

Using the most general category is no different than using an int, but back
to the point above: Where is the advantage of the rich enum type if a
single <=> in the most general case, even a trivial one, does not behave as
intuition suggests?

On Wed, Sep 27, 2023 at 7:13 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Sep 27, 2023 at 7:45 PM 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.
>
> But that is *exactly* what people will do. All you've done is
> introduce fragility to the system, where `int` in one place doesn't
> really mean `int`.
>
> There is a *very* long-standing convention in C code for 3-way
> comparison functions to return a signed integer where the sign
> represents the directionality of the comparison. And I'm not just
> talking about the standard C library functions like `memcmp` and
> `strlen`. Pretty much any 3-way comparison function that returns an
> `int` *does not* require that the integer is on the range [-1, 1]. All
> values are valid, and the only thing you're expected to test is the
> sign (or zero).
>
> C++ explicitly didn't want to engage with this convention for its
> 3-way comparison operator. So they created a *new* convention: the
> ordering types. It's a convention that gives you a *compile error* if
> you try to directly return the result of `memcmp`, but if you return
> `memcmp(...) <=> 0`, it works fine.
>
> That's what good design looks like: noisy errors when you do it wrong,
> and easy to do it right.
>
> You are trying to invent your *own* convention and crowbar it into
> C++. A convention that is syntactically identical to the established C
> convention, but is semantically incompatible with it. And because of
> that, there is no compile-time test to know whether you're using the
> C-convention or the Chris-convention. You can do it wrong and get
> silently working code... until someone does the wrong thing and it
> doesn't work anymore.
>
> That's what bad design looks like: errors are allowed to creep into
> code and make it appear to work... until it doesn't, and with few
> pointers to where things went wrong.
>
> 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`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>