Maybe a slightly faster std::regex or whatever it's called; apparently it's horrendously slow for no benefit.
C++ is unique in that it defines a spec for STL but not implementation. The result is something that is both overspecified and underspecified.
Including batteries is fine. Including a spec for what the batteries should look like is such a profoundly bad idea that no other major language does it.
There is absolutely no reason for std::deque to be a specification. The committee should either ship a committee library for std::deque or they should leave it to the community. They can provide a battery or they can not. Providing a spec for a battery that is both over and under specified is the absolute worst possible choice.
The standard library on the other hand is a library. It's almost always implemented as plain C++ without much platform specific code. ISO could take an existing free licensed implementation and declare it as the standard. Of course anyone is free to make their own competing one, it just has to always match the official library's behavior.
Writing a spec instead of code is just creating duplicate work and compatibility issues any time the spec is unclear.
Why on earth would I want a different implementation of std::deque on each platform I use because the compiler team needed to provide one? It’s madness!
I remember a language where the core language types, including primitives and a bunch of keywords, were actually defined in the standard library and the compiler just special cased support for the types in the standard library for optimization purposes.
Your loaded question feels very silly from that perspective.
The real problem is the latter: C++ has always had a "you don't pay for what you don't use" as part of its core philosophy but it turns out that doesn't apply if the thing you don't use is ABI stability.
(and, failing an ABI break story, std::regex should have had an implementation that was more PIMPL and less template so it would have fewer ABI issues, possibly followed by a regex2 later that could get more of the compile time bits once implementations were more mature.)
I think even if C++ had a periodic ABI break that even a better std::regex spec is fundamentally wrong.
As someone who ships cross-platform I never ever want different platforms to have different implementations for things that are not actually platform specific. Having different implementations of std::string depending on if I’m on windows, Linux, Mac, iOS, Android, PlayStation, Xbox, or Nintendo is a profoundly terrible thing to do.
C++'s separation of spec from implementation is clearly functional. There are several major open-source standard library implementations that compete on the basis of performance, ABI stability over versions, quality, etc.
C++'s core ethos is "only pay for what you use". std::regex does this. In my experience, the "problem" with std::regex is that it provides more features by default than most people want, and you pay for using those features. Specifically, std::regex respects the runtime locale. There are good reasons a standard library feature might do this (e.g. it simplifies the interface, it's broadly applicable, etc.), but it's obviously not going to give optimal performance. This is a necessary tradeoff for any standard library.
Locale handling requires dynamic memory allocation, virtual function dispatch, sometimes system calls. Locale handling also prevents some low-level optimizations based on the character encoding. If you need that kind of performance, std::regex probably isn't for you, go grab a non-standard library that suits your needs.
std::regex is so worthless that no one uses it. My codebase gives CI warnings when it’s used. so it’s not even really a problem. It is indicative of a larger problems.
> C++'s separation of spec from implementation is clearly functional.
Your bar of “clearly functional” is is not a compelling or meaningful bar. What a weird fallacy.
C++11 was pretty great and meaningfully modernized the language. The amount of useful good things in each following release got smaller and smaller. Maybe just one or two useful improvements in C++20. Almost nothing in C++23. And now C++26 has failed to pass. It’s grinding to a halt. The biggest recent features such as concepts and modules have been catastrophic failures.
Those failures aren’t all due to my specific complaint of “battery specs are a bad idea”. But “functional” is the lowest possible bar. And one could argue that as a whole isn’t being met.
Spoiler alert: The option described as "the sort of leadership failing that I pray we can avoid" is what ended up happening.
It is a huge pain, and quite honestly, most of the reasons I have to maintain ABI are political and thus not up for a technical discussion, but I still have to do it.
It's just bureaucracy preventing it, not the actual work needed by people.
It's not too late to introduce an actual stable ABI though. However, it's not too late to do that in Rust either so I don't see the point in a language specific ABI in the future anyway.
I mean, I mainly say this to joke because it's probably unfixable at this point, but whenever I mess with it, I'm struck by how hard/opaque C++ makes this problem compared to most other languages.
Large FAANGs that would be incentivized to change it don't care because they have their own in-house C++ build systems like bazel (Google) or buck2 (Meta) that are far faster than cmake (distributed compilation and caching) but require huge teams to maintain. Unfortunately, this distributed compilation and caching layer is something that many other languages don't have since their build systems are made for single devs building locally.
Also the dependencies can be added in a myriad of ways. Your build system can download them, your meta-build dependency manager can find them (Conan), your Linux distro can provide them (system libraries), or maybe you just download an object file from a website + some headers and are told to figure it out yourself (many commercial packages like cuda or steam).
So this is only a painful problem for people who don't use C++ very much, and whatever centralized, official solution to builds would probably not really get adopted by most C++ shops.
Because of that, even if it were solved, it's likely that it would only solve the problems that people who don't use C++ very much, or who don't invest in build tooling, want fixed. Which is basically what Make was originally.
IMO it's best to think of C++ as a language only. Because of Microsoft/Sun/the web/etc and the desire to win over developers' business, a lot of newer languages are designed to be batteries-included with official first party tools that are supposed to be the canonical way to solve that particular class of problems. Those languages are essentially products or brands that are part of their benefactors' grand designs for specific business or career outcomes.
C++ by contrast has multiple competing implementations for basically anything you can think of, and isn't someone's "business" the way most other languages are, so there's no reason to make the out-of-the-box DX better or standardize the tooling. Nobody has any reason to want you to write C++ instead of something else.
C++ is used for large, very, very, very, very complex problems. Language-specific build systems always like to assume all the world is their language. But not all my world is C++, just 99% and that last 1% is all kinds of weird, screwy things that require a very complex build system. CMake is up to the task, in part because CMake is used for building more than C++ and so they've thought a little bit about the issues I have.
Anyone who says CMake and C++ are complex languages is utterly completely wrong. Sure, by comparison to something better designed, they're a little more complex, but we're only talking a little bit. Meanwhile, I have tens of millions of lines of code to deal with. My real complexity isn't the language, it's my code and that is far greater than all these little complaints people have about the language complexity.
I mean, it is a real problem, it is making life hard on developers for no good reason, but sometimes, artificial friction can work against some anti-patterns. Similar in spirit to "chaos engineering".