C++17 introduces the std::filesystem library which contains plenty of useful functionality. Operating system specific handling is abstracted away into a standard library, there are very useful and carefully designed types & functions to interact with. For example it introduces a proper path object type that is way more convenient and secure to use than the C-string manipulation we do in Blender currently.
It would be great to be able to use this as it would make file system interaction much easier, better tested/maintained, better designed (arguably ;) ), better documented and actually standardized (hence more familiar for devs coming from other C++ software). Sybren and I would like to use it ASAP for asset system related code.
According to the C++17 compiler support overview we can't use std::filesystem with our current minimum requirements. We'd need to drop macOS 10.13 and 10.14 and possibly Visual Studio versions until 2017 15.7 (current minimum version only states 2017).
- We can't use XCode 11 until macOS 10.15. In 10.14 it can only be used by creating an Apple developer account and manually downloading it.
- 10.14 is the last version of macOS to support 32 Bit. We can expect a decent amount of users to stick to this release for 32 bit games and applications.
- The VFX Reference Platform draft for 2022 foresees macOS 10.15 as Minimum Deployment Target.
Conclusion: We may be able to update our requirements before too long, but as of now it's too early. In other words, we can't use std::filesystem yet.
std::filesystem vs. BLI functions
We have other options than using std::filesystem directly. But there's another discussion point:
Blender already has library functions for file system and path handling, all written in C in BLI. Concerns were raised about using std::filesystem while the BLI APIs also exist with entirely different implementations. Porting the API would probably take quite some effort & time, and could cause dangerous regressions.
- Use the following, light-weight, std::filesystem compatible implementation of the API: https://github.com/gulrak/filesystem
- Encourage usage of that for new C++ code.
- Cover BLI file system & path APIs well with unit testing.
- Gradually port BLI APIs to use it for internal logic.
We could change the BLI API designs a bit, e.g. rather than passing paths as character arrays, have an opaque path handle that uses ghc::filesystem::path internally. Path operations would have to be done through the API then (which may have to be extended a bit). Generally we should aim for getting the API as close as possible to std::filesystem.