Hi Chris, Headers != Standard Library   One is (for the sake of user code) about identifiers, the second is, how that code is implemented.   1. It would probably be possible to implement "compare" not as real standard library header file, not even a real file at all, but have #include <compare> make {strong|weak|partial}_ordering visible in namespace std, so it is fully implemented in the compiler. So no reliance on the standard library needed.   2. OTOH one could propose that <compare> is included by default. So no need for #include or #import.   3. Or one could propose that #include <compare> declares those identifiers in the global namespace. No need for std::.     1.-3. are three different (even orthogonal/combinable) proposals/ways of implementation. It is not really clear, which of those you are promoting (besides changing the type to int, which I am not going into here). Probably all three?   Best, Sebastian   PS 1. Not implementing <compare> as a standard library header file is kind of partly fulfilled with modules, as no headers are inserted by the preprocessor into the TUs. So the feature is *slightly* shifted more into the direction of a language feature vs. a standard library implementation. At least the effects of importing it can be more exactly be specified than including a header file anywhere in a TU.   -----Ursprüngliche Nachricht----- Von:Chris Gary via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 25.09.2023 04:38 Betreff:Re: [std-proposals] Let spaceship return an int An:std-proposals_at_[hidden]; CC:Chris Gary <cgary512_at_[hidden]>; 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] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org>    Software Architect - Intel DCAI Cloud Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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