On Mon, 25 Sept 2023 at 00:40, Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> Oh, so what you're saying is that basically every single argument you
>> made in this thread thus far was a subterfuge. All that talk about
>> `int` being "easier to use," or "It must be possible to effectively
>> use the language without the library" and so forth was just a
>> smokescreen.
>
>
> `int` is easier to work with. There was no smokescreen. What happened: Architecture astronomy.

Yeah, well. Comparison results may certainly map to ints, but not all
ints are comparison results, so using int loses that distinction
straight away.

> There is a branch-free way to test for set containment, any compiler can implement the implied rules without any more overhead than the existing solution, and doing away with another need for an import or an #include is always a good thing.

This suggestion doesn't do away with a need for an import or an
#include. That need remains, because instead of importing std or
including <compare>,
I now need to import or include "my_compare.h", and when I move to the
next project, I need to find out what their version of the same idea
is.
Because nobody who wants to program with this is going to say "just
fiddle with ints". They're going to at least add enums for various
comparison
result values, and most likely make the operators return objects of
class type, and have those class types compare to the enums.

And what does that give us? A custom implementation of <compare>, but
instead of having three of them, we now have ten thousand of them.

> I feel as though I'm having to spell out my position over and over again, so its a bit aggravating.

Perhaps we can't fathom how your position leads to any sort of
improvement, considering that we have massive trouble understanding
the rationale, if there is one, behind the claims and IMOs that you posit.