Feature request: Add std::filesystem::path overload for file_stdio::open

[Eelis]

file_stdio::open currently only accepts a char const* path. Recently I had a std::filesystem::path and wanted to call file_stdio::open, noticed that I had to do mypath.c_str() to make it compile, briefly thought "hm that's a bit weird", but it worked and I didn't think further about it.

Then a week later, I noticed my code no longer compiled on Windows, because there, mypath.c_str() returns wchar_t const*(!). For the time being I made the compiler shut up by doing mypath.string().c_str(), but I'm not even sure that's correct, and really, it just made me wonder why Beast is doing this to me. :-)

Update: I see file_stdio::open specifically requires UTF-8, so maybe I should be using reinterpret_cast<char const *>(mypath.u8string().c_str())? If so, that's not the most ergonomic API for opening a file specified by a std::filesystem::path.

[ashtum]

I believe this is an intentional API design decision, following the UTF-8 Everywhere philosophy (utf8everywhere.org). The rationale would be that Beast is a networking library and paths typically originate from network data (e.g. HTTP request URIs), which are already UTF-8 encoded. It's more convenient to store, pass and manipulate these paths in UTF-8 throughout the application, rather than converting to platform-native encodings at every boundary. The char const* UTF-8 contract keeps the API simple and consistent across platforms, with the platform-specific encoding conversion handled internally by Beast at the point of the actual system call.

[Eelis]

keeps the API simple and consistent across platforms

Well, it achieves the exact opposite: in order to use this API across platforms with a portable std::filesystem::path, I have to write platform-specific code.

[ashtum]

keeps the API simple and consistent across platforms

Well, it achieves the exact opposite: in order to use this API across platforms with a portable std::filesystem::path, I have to write platform-specific code.

Yes, that statement is based on the following assumption:

It's more convenient to store, pass and manipulate these paths in UTF-8 throughout the application, rather than converting to platform-native encodings at every boundary.

A std::filesystem::path does not guarantee UTF-8 encoding, so it cannot be treated as a UTF-8-only container.

[commmrade]

I wanted to implement an overload for std::filesystem::path or for boost::filesystem::path but I came across a problem which is to be exact the fact that these 2 may throw when doing conversions (std::filesystem::path::u8string(), boost::filesystem::path::string(codecvt_type). So I guess only having open(const char* expected_to_be_utf8) was a pretty wise design choice, because now it is up to the user to make sure path is valid UTF-8 and so on.
I guess, it is possible to implement these overloads using a WideCharToMultiByte (obviously non-throwing) for Windows and the fact that POSIX does not require filenames to be UTF-8 and it is just a sequence of bytes (excluding '/' and "\0"), therefore it is possible to just call [insert_library]::path::native() which does not throw and pass this into underlying file implementation.
If it is a good idea, I wouldn't mind implementing it