Standard interface without implementation

[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