That's the point. The three-way comparisons don't return
an int because they tell you that you shouldn't just accidentally
return them onwards
...

Don't use return types to influence the design of an API?
It sounds like everyone again discovered that operator overloading just means symbols can mean anything, then tried to "fix" it with a sledgehammer to everyone else's head.

IMO, the language should avoid imposing complex semantics that require having to import symbols to use a syntax feature.

The part about my dislike of library headers is not about just the standard. More headers means more coupling, and just like any other evolving framework, everything I use in std needs to be wrapped when contending differences between implementations. There are numerous situations where I've had to make explicit use of the actual compiler hooks in order to get otherwise standard features to work. One of the most recent was bit_cast<> which was working, then it stopped working, then it started working again. Thanks to a wrapper, which I should not have needed to write, the project could move onwards despite the new issues.

Point being: The fewer wrappers around basic things that need to be made in cases like this, the better.

On Sun, Sep 24, 2023 at 3:14 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On Sun, 24 Sept 2023 at 23:57, Chris Gary via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>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).

Yes, bingo. That's the point. The three-way comparisons don't return
an int because they tell you that you shouldn't just accidentally
return them onwards
as ints without thinking about what you're doing. And your code using
three-way comparisons is then less likely to just do the wrong thing
because it
would happily get an int and could think it can process it further
even though the results are already balderdash, like they are for
NaNs.

I get that you would like to have a different model, and still be able
to invoke that model with an operator<=>, but allowing that means
that three-way comparison loses the semantics of the conceptual
framework that it has, and becomes just a random DSL that can mean
whatever the user says it means. Which was one of the major problems
of earlier attempts at a "model" with operator< etc., they were and
are abused to create something completely different from comparison
operators. Three-way comparison was designed to avoid the allure
of creating a free-form DSL, and attempts to keep the conceptual
framework intact, so that the syntax doesn't have an open-ended set
of semantic meanings.

The benefits of that are ostensibly greater than the benefits of the
free-form DSL would be, especially considering the downsides of that
free-form DSL. The dislike of using library headers is a complete
non-issue, you're going to be doing 'import std;' anyway.
If you have a dislike against using the standard library at all, too
bad, you'll need at least a freestanding one to opt into this
framework, and that's just going to be that.
The rationale for being able to write programs without any sort of
support library at all are too unconvincing to make drastic conceptual
changes,
as my technical educated guesstimate on this.