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.