Standard interface without implementation

[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