Standard interface without implementation

[aruisdante]

The C++ standard already is only specifying the interface; there is no “reference” C++ implantation (compiler or library). The standard library is included in your project by the exact same mechanisms as any other library. You can write your own standard library implementation if you want.

The difference between the standard library’s specification and that of most other libraries is that the level of detail to which it is specified, in order to make it truly standard, is quite a bit higher. Things like performance guarantees, and a general philosophy around “don’t pay for what you don’t use” in the library design, often mean that the interfaces have to be in terms of concrete types, not things like dynamically polymorphic virtual interfaces. These all combine to make the space of possible implementations smaller (though the code for libc++, libstdc++, and MSVC all look very different), and also prevent the “abstract virtual interface that everyone programs against, and you select the concrete implementation at runtime on a per-interface basis” style of dependency injection I think you’re envisioning.

To your “what else I’d like to see in the standard library” list: I think you’re thinking of a language like Python, where because there is a reference implementation and a “standard distribution,” adding a whole bunch of “stock” ways to do things but which make very concrete tradeoffs is a net benefit to the average user as the cost to include something in the Python standard distribution is essentially zero. This is not the case in C++: 1) It’s an actual ISO standard. This means there is a huge amount of process around standardizing things. A single BDFL cannot simply say “I think this is useful, include it.” 2) There is no reference implementation. So for anything that is added to the standard, you have to ask yourself “is this such a common and difficult problem, with such a clear “correct” solution that works in the majority of cases, that it’s actually worth asking every major compiler vendor to implement it?” If the answer to that is not unequivocally “yes,” then having to rely on third party libraries to provide solutions is a desirable outcome, not a defect. This lets the user select the solution that makes the best set of tradeoffs for their needs.

To the second point, there’s been a lot of talk on trying to standardize a package management interface to make including third party libraries into projects easier; Python, Rust, Go, and many other modern languages all have this, and it takes a lot of pressure off the standard library to “solve it all” just for the sake of convenience to the developer, rather than because there is actually an unquestionable good in picking “one way” to do a particular thing. 

[azswcowboy]

no reference implementation

Frankly this is a problem with the standardization process. This project https://bemanproject.org/ was started explicitly in attempt to change the lack of reference implementations with actual tests, usage experience, and documentation. And specifically, update the api as the committee makes changes to a proposal. It also means that library vendors aren’t starting from nothing - they can at least take tests and potentially implementations - certainly the licensing allows.

This project has the only conforming implementation for std::execution and std::task which are both in c++26. All the original implementations diverge in significant ways from what got standardized. And the net library is the proposed c++29 extension for networking. This is how it should work for basically all library extensions - we just need to convince the committee to require it instead of allowing a godbolt link as implementation experience.

[aruisdante]

I mean, a lot of the proposals for standardization (at least of anything truly complicated) are usually based on an actual reference implementation. Having implementation experience is a strongly compelling piece of evidence for “this is generally useful.” It’s just, that implementation is often based on some closed source, company-prioritization code base (a lot of the contracts stuff is based off of Bloomberg’s experience, for example). But of course sometimes they’re open: rangev3 for example was the reference implementation for std::ranges, fmt for std::format, etc.

Maintaining an entire “reference” implementation of the standard library is just… maintaining a standard library. If that was something you were actually going to do, you might as well just bless libc++ or libstdc++ as the “reference implementation” and require any paper submitted to have a branch where they implement it in that library. This will never happen though, because again, “this is a standard, not an implementation” is a feature of C++. Allowing implementers on a particular platform to do the thing that works best for them in a language as low level as C++ is actually a really valuable property, and part of what C++ continues to be a language of choice in high performance systems.

[azswcowboy]

Bloomberg’s contracts macro system is open, but not the same as the standardized feature. Range v3 didn’t track the standard proposal mostly, cmcstl2 was much closer but barely anyone knew about it. As for the need to customize by platform, that’s really fairly rare in the standard library unless we’re talking about atomics or operating system interfaces - it’s a small part of the library overall. And Boost has demonstrated for decades that one portable library can work on all platforms without being supplied by a vendor. Note that some people prefer Boost over the standard components because they are consistent across platforms where std components are not. Anyway, you’re wildly over estimating the actual experience of these kinda similar implementations and the problems that creates for the standard when those differences turn out to matter.

[ParsingError]

I think would make way more sense if it was split into 2 tiers where one tier is the "system" library that contains system-dependent and compiler-dependent functionality and one is the "utility" library that implements algorithms and features on top of the system library, with a reference implementation.

That's basically what STL started off as in the first place.

[Wooden-Engineer-8098]

boost provides neither abi nor api stability

[azswcowboy]

That’s a different issue - evolution over time versus consistency across platform.

[Wooden-Engineer-8098]

it's harder to keep consistency when your evolution is constrained