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

operator new, delete, etc... can be used without a header.

Several years ago, I wanted to try something like TLSF with a few ideas of
my own, which required writing malloc, free, etc... operator new is just a
malloc wrapper. I'll add that it was worth the effort.

I'll just say the thread might as well be closed for now, since its either
venom or just walls of text about the obvious.

My $0.75 (adjusted for inflation):

Headers: bad
Syntax: fun and elegant
Syntax that needs a header: what?

I actually brought up this issue and many others (elsewhere) before the
proposal was final, and was met with the same tidal wave of venom. IIRC,
the committee has never taken issue with ABI breakage, and even in my
personal projects I really do not care about that kind of thing.
Re-building everything is already implied from one release of the standard
to the next, so any point made on the basis of ABI breakage is moot, IMO.

It seems presenting ideas here without first providing a toy implementation
never gets any traction. "If you can't hack it into Clang, then nobody
cares."

I'll have to come back to these things later.

On Sun, Sep 24, 2023 at 5:19 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>