On Mon, 25 Sept 2023, 03:38 Chris Gary via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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

lol

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