It's quite sad IMHO that there are no sub component headers offered - only these massive collection headers (<filesystem>, <string>, <algorithm> - as opposed to boost's path.hpp etc.), yet then we don't even have some ...fwd headers standardized either (other than <iosfwd>).

https://github.com/ned14/stl-header-heft

Makes one wonder whether the committee did its proper job for non-sunshine-path situations (multi-million LOC code-bases), and whether it is such a good idea to be designing minimalist interface headers with filesystem-specifically-typed arguments - perhaps one would choose to resort to plain string-based filesystem item arguments then...

Not to mention that std::filesystem appears to be more problematic encoding-handling-wise than boost::filesystem (see discussion on SO) - but I digress.

| Could you make such a header? Also, no.

That's why IMHO it is very important that API providers do also supply official/central fwd.h headers for their (changing!?) types. Since it is not the consumer's job to be doing dangerous guesswork.