[bregma]

I've been writing C++ for well over 30 years. I'm currently employed full-time maintaining the C++ toolchain, runtime, and standard libraries for a major commercial embedded OS. I see a lot of C++17 being used by my customers every day. It's there, running everything around you.

C++20 is still too fresh for my industry, especially for embedded where runtimes require certification for functional safety. Maybe in two years.

What can I tell The Committee? Stop. No, we don't need a single central ex cathedra library for networking. Or graphics. Or SIMD. Even the existing filesystem library is so broken it's dangerous (the standard specifies if it's used on an actual filesystem it's undefined behaviour -- which means using <filesystem> means your program could provoke the legendary nasal daemons just by being run). Stick to generic basics and leave the specialized stuff that not everyone needs to third-party libaries. Nothing wrong with a marketplace of libraries to serve an entire economy of requirements.

[d0mine]

Standard SIMD everyone can build on top of sounds like a great idea--no unnecessary fragmentation due to using different subtly (or not) incompatible libraries. SIMD instructions are in desktop CPU since 90s. It is long overdue.

[jb1991]

You are saying that the standard specifies that the standard file system features themselves do not work?

[skitter]

If another program (or thread) is using the same filesystem, calling std::filesystem functions can be UB.

> Behavior is undefined if calls to functions provided by subclause [filesystems] introduce a file system race.

http://eel.is/c++draft/fs.race.behavior#1.sentence-2