On Sunday, 24 September 2023 15:15:05 PDT Chris Gary via Std-Proposals wrote:
> > So what's the problem with the current implementation?
>
> #include <compare> // <-- has a bigger maintenance footprint than it seems.

Maintenance footprint for whom? You didn't write that header, you're not
expected to maintain it. It is a bigger footprint for the compiler vendors,
indeed, but they didn't complain about that when this feature was proposed.
You'd think the affected people would raise.

So why are you raising on their behalf now?

> Did I use a library feature? No, I just wanted to use <=>...

You also want to use "new" and that's a library feature. You may want to use
dynamic_cast and, even that's similarly a library feature. Heck, sometimes
multiplications or divisions are runtime library features too.

BTW, I would usually agree that Core Language features shouldn't require
including a header. That's how nullptr works and that's also how _Float16 will
in C++23 (I think). I am the person who maintained Qt's "-no-stl" build in Qt
4.x and proved that it compiled much faster. I'd have preferred if intialiser
lists didn't require <initializer_list>.

But I am of the opinion that some things are worth headers. <type_traits>
comes to mind, for example, or <limits>. So why not <compare> too?

> That's really it for now.

That's not enough. If you had raised these arguments 4 years ago, maybe they
would have been acted upon because there was still time to act (I doubt,
because they're weak).

Right now, you need to show there's a major problem. You haven't and you're
saying that there actually isn't.

> The rest is just "let me use my own int-alike" and why that is possible.

You *can* use your own int-like type or even int itself for your own types. Go
ahead and define that as the return value for your operator<=>.

Let's see what your users say when they try to combine your types with someone
else's. I'm not even saying that those users use the <compare> types; just
what happens when this other library uses types different from yours? You can
claim that combining int results is easy... well, so long as one doesn't have
to worry too much about unorderable compares. But why reinvent the wheel for
every library and type combination?

Finally, maybe you should look at how *compilers* actually implemented this
feature. You *can* mostly do what you're proposing. We're discussing right now
how to implement C++20-like three-way comparisons in C++17 so that all our
users can benefit from it. That involves creating QStrongOrdering and
QWeakOrdering types, to complement QPartialOrdering we added a few years ago.

> I'm getting responses as though I've somehow gone home-to-home and kicked
> their pets.

No, but you also seem to be completely oblivious to the consequences and
severity of what you're even talking about.

You're proposing a major ABI and source-breaking change without showing that
the harm you're proposing is required and that it's worth the harm we're right
now incurring. You have an opinion -- which you're entitled to -- but don't
seem to have arguments of why your proposal is required *now*. So unless you
have a time machine that you can use to send this proposal to 2019, you need
to justify it in that light,

(BTW, in case you do, maybe you should let us know to stock up on masks and
toilet paper)

You can present a "what-if" scenario. That may be an interesting case-study,
but it can't be more than that.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering