> It's the same issue with the existing standard POSIX API It's only an "issue" if you look at this as being an attempt to create a be-all end-all API, and it

> It's the same issue with the existing standard POSIX API It's only an "issue" if you look at this as being an attempt to create a be-all end-all API, and it isn't. Things like std::filesystem (and POSIX file APIs) are made not to replace the native APIs but to complement them. They exist to fill the need for cheap, simple auxiliary tools, not the need for high-performance tools. In other words, std::filesystem doesn't exist to facilitate writing a high-performance whole-filesystem search engine. It exists to facilitate writing high-performance audio analysis tools, image manipulation libraries, funky customizable desktop widgets, or really any conceivable program which uses the filesystem, but never in a hot loop. It exists for the same reason std::string exists in spite of the fact that it would a terrible core data structure for a text editor. It exists for the same reason std::iostream exists even though you would have to be insane to try to write an HTTP engine with it. It exists because when you need to load up three 200-megabyte files to grab the input for an hour-long simulation, you don't care about an extra five milliseconds at startup as much as you care about dead-simple, reliable code. Or maybe you do, in which case you can still happily use the native API.