On Mon, 25 Sept 2023 at 00:26, Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> 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.

No, everyone didn't discover that again, because that's not what
operator overloading means, nor is it what it ever was supposed to
mean.
Operator overloading facilitates generic(*) programming with a compact
notation, but you can't do generic programming if your semantics
are an open-ended wild west.

(*) And this doesn't mean templates, necessarily. It means
understanding what a syntax construct means, meaning that its
semantics
should be unsurprising. So operator+ doesn't do multiplication, even
though you can make it mean that in a DSL.

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

A suggestion with zero rationale. The language should absolutely do
that; when the semantics are complex, the language's
standard library should provide helper types that ease working with
those semantics. Otherwise the language would provide
no support for those semantics at all, leaving it to the users'
headache to get the semantics right. Something that low-level
shouldn't come with a shorthand syntax like operator overloads, it
should be spelled as
std::excruciating_detail_here::manipulate_itty_bits().
When we are actually building something that's not itty bits, but an
actual higher-level thing, such as Ordering, we should bloody
well implement it in the library so that it's actually debuggable, and
then have a language construct transform the code into calls
to such library code. You know, as opposed to implementing all that
deep inside a compiler, where you can't debug it. Or not
implementing it at all, and leaving it to every user's concern to
build Ordering on top of.. ..almost nothing.

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

That's not better. You're suggesting there that just because one of
the libraries you used had a bug, those bugs should be hoisted as the
responsibility
of every user. You don't need those wrappers once the standard library
implementations mature and stabilize, because the goddamn standard
library
provides the wrappers you need, it provides the vocabulary types you
use when programming with three-way comparison, and you don't need
to invent your own vocabulary types, and neither does anyone else.