>
> 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_at_[hidden]> wrote:

> On Sun, 24 Sept 2023 at 23:57, Chris Gary via Std-Proposals
> <std-proposals_at_[hidden]> 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.
>