>
> So what's the problem with the current implementation?
>

#include <compare> // <-- has a bigger maintenance footprint than it seems.
Did I use a library feature? No, I just wanted to use <=>...

That's really it for now.
The rest is just "let me use my own int-alike" and why that is possible.

I'm getting responses as though I've somehow gone home-to-home and kicked
their pets.

When you present an idea in a forum and the first thing you get from a a
few people who, for all intents and purposes, you should expect to behave
in a professional manner spit out one "go foad" after another its hard to
gauge the community temperament.

On Sun, Sep 24, 2023 at 4:03 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday, 24 September 2023 13:57:38 PDT Chris Gary via Std-Proposals
> wrote:
> > enum class Relation : int
> > {
> > Undefined = -2,
> > Less = -1,
> > Equal = 0,
> > Greater = 1
> > };
> >
> > inline constexpr Relation ClampToValid( Relation r ) noexcept
> > {
> > const auto u = (int)r + 1;
> > const auto v = 2 - u;
> > const auto w = u | ((u|v) >> (bitCount<int>-1));
> > return (Relation)( w - 1 );
> > }
> >
> > // Relational operators that take "Relation" etc...
> > `
> > Now, if <=> could just return `int` or anything that can round-trip to an
> > `int` implicitly, *and* enum classes could expose implicit conversions,
> > this could all be safely encapsulated without creating incorrect code
> that
> > tries to compare a `Relation` value and not getting the magic `undefined`
> > result - everything would get mapped into to the set {-2,-1,0,1} before
> > comparison. The "sign of difference" rule still applies everywhere, and
> > comparisons are allowed to return any other random value to mean
> > "undefined". In cases where the meaning of the return value means more
> than
> > just "undefined", and the code still assumes the semantics of "Relation",
> > it wasn't written to deal with the failure anyway (generally, just
> capture
> > the original int and propagate an error/throw an exception).
>
> I'm missing something.
>
> How is this any different to std::strong_ordering?
>
> The implementations do use values -1, 0, 1 and something else (2, -2,
> -127,
> etc.). They just happen to wrap them in a class that can relate to
> partial_ordering, weak_ordering.
>
> So what's the problem with the current implementation?
>
> --
> 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
>