On Sun, 24 Sept 2023 at 23:15, Chris Gary via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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


The proposal's rationale is just "I don't want to include a standard
library header". That's a waste of time, it's not going to go anywhere.




>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>