Hi all,

The question is in the subject. Please list five libraries that you would have liked to be part of the standard C++ library, and tell me your reason(s) for them.
Thanks in advance.

https://www.boost.org/ is an incubator for future standard library candidates.

... parts of boost. Much of it should be avoided.

@kbw
What parts, especially, should be added ?

Not specific libraries, but functionality:

json
xml
csv
big number
communications (big topic - possibly for C++26?) - What's happening with SG4?
specifically a network stream that enables all the stream operations to also work across a network/internet.

From http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0592r4.html

Library support for coroutines Coroutines are in C++20. The only problem is that users can't do anything with them, because there are no types that are coroutine-aware. It should be fairly non-controversial that we need to fix this problem in C++23. What exactly are the coroutine-aware types that should ship in C++23 is to-be-defined by LEWG, but in general, the expectation would be that there are task types that would be plausible, but we should also take another hard look at which existing standard types could or should be made coroutine-aware. At any rate, the standard library should provide some coroutine-supporting types out of the box. A modular standard library Now that Modules are in C++20, C++23 should ship with a specification of how the functionality of the standard library is exposed as modules. While there are many arguably important libraries to modularize, the standard library is a very significant one, and should allow users to reap the benefits of modules. Executors We need executors for half-everything; we need them for networking, we probably need them for audio (if we go further in that direction), we need them for heterogeneous hardware, we need them for a better async, we need them for better task types. We have been working on executors for quite a while, and in C++23, we should deliver. Networking We should lower the barrier of writing networked C++ applications. We have a TS, we have years of existing practice, so once the blocker item is resolved, we should standardize networking. This shouldn't require much more rationale, but once the foundational facilities are in the standard library, writing cross-platform http code that requires no additional libraries to be built is right around the corner, and we should make that possible.

Yes, networking is way up there.

big number, and access to IEEE types supported by the hardware (eg direct 80 bit floating point type, whatever other common hardware sizes).

maybe a STL container for generic graphs (supporting trees as well).

maybe it is time for language supported serialization, at the very least for STL containers inside objects.

but instead of piling on more crap, I would love to see a cleanup pass. They hit at this a little here and there, removing and updating, but it needs a full going over not more drive-bys.

Thanks for your answers.

What parts, especially, should be added ?

much of boost funtamentals have already been taken (ref, smart pointers, optional, ...)
asio is really good, not great from a programmer's perspective, but it makes all the right system calls underneath
spirit - broken
json - broken
can't remember too much off the top of my head.