I want to learn from how some existing, well-known, well-established languages define their standard libraries. As a first step- before getting in to the deeper "why" questions, I want to just understand the "what". (I'll ask "why?" later as a follow up to this).
What criteria do library feature proposals generally need to meet for the C++ Committee to add (or consider adding) to its standard library? What's the overarching theme that ties those criteria together?
Bryce Adelstein Lelbach spoke on this in the CppCon 2020 Standards Committee Fireside Chat at t=17:16 (Bryce is the chair of the Standard C++ Library Evolution group at the time of this writing and was at the time that video was recorded).
For context, the question asked before the referenced clip begins was:
C++ does not have a standard or even de facto logging API. Do we need to do something in the standard to catch up with other frameworks?
Bryce gave a generalized answer on how the C++ Committee decides what goes in the C++ Standard Library:
(I have stripped out some "filler words" from the quote like "um", "uh", "so,", etc. and added the numbered list formatting).
I think there are a lot of things that we could add to the Standard Library, and a lot of things that exist in other languages' standard libraries, but in the C++ standard library, our priorities and the things that belong there [are] limited to a specific set of high-value things. Essentially, the things that I think belong in the Standard Library are the things that cannot go anywhere else. There's a few different categories of these things:
[...] Vocabulary types.
You can't really have vocabulary types anywhere other than the Standard Library because the whole idea of vocabulary types is that it's a common type that everybody agrees upon.
[...] Instead of your library having a string type, and my library having a string type, and the third person's library having a string type, and then some user who's trying to use all those libraries having to traffic in multiple different string types, you have one string type- or as it is now, you have one string interface type-
string_view.[...] Abstractions around the platform.
[For example,] the concurrency library or file system. You could get a third-party library that could provide an implementation of those facilities for you, but oftentimes you want those facilities that are specific to your platform to be provided by the vendor for your platform. The person who's providing you with your C++ implementation on your platform is probably going to be best equipped to give you [...] the implementation of the abstractions for their platform. If I'm on Microsoft, I want the concurrency facilities that have been designed by the Microsoft engineers and designed to work well with MSVC.
[...] Things that require language support-
standard library facilities that aren't actually really standard library facilities, but are really just extensions of the language. For example,
<type_traits>[...].Those three categories of things [...] are the primary priorities that we have because those are things that cannot be satisfied by any other library other than the Standard Library. So we have to focus on those first as our priorities. There's so much that we could do, and we still have a lot to do to even satisfy all the things that fall into those categories.
Now, something like a logging library, that might be nice to have, but the question is: Is it essential? Can we add greater value in having a standard library logging facility instead of- say- working to make it easier for people to use third-party libraries so that you can use some awesome third-party logging facility. So I think that unlike in other languages, in C++, our focus should be on a really high quality but focused standard library. But then, we should [also] be spending more effort on making it easier to use third-party libraries which means enabling things like packaging, et cetera.
(For what it's worth, Tony Van Eerd follows up at t=22:42 on the discussion with a point that there could be value in having a logging interface as a "vocabulary type" in the Standard Library (along with some other good points before that)).
Bjarne also follows up at t=27:23 getting at a point that the C++ Comittee likes or would like to let the user community experiment with library designs for things that could make good future standard library proposals and let community preferences emerge over time, and use that to inform design decisions:
We have to remember that other languages in the former sense tend not to have standards. I mean Java, Python, etc. They don't go through an ISO process and have a formal specification or all that stuff. Instead, they have good distribution mechanisms like Bryce pointed out we need: packaging distribution, central places for storing things, and that way you can have- sort of a [...] shootout before something wins and becomes a de facto standard. [...] If we could get a decent package manager and distribution system, I predict [the C++ Standard Library] would have a logger within a year. Because there are several good ones. They tend to be corporate or not that widely available.
(I think Boost has historically contributed to examples of this kind of thing happening (related on Stack Overflow: Boost Libraries that made it into the C++ standard))
You'll also notice that the committee members are very aware of needs to better tooling (including package management as a subset of that). If you're interested in that, see Working Group 15 (the tooling working group) and their work.
