Maybe all that is needed are updated guidelines. Here is an example use case I ran into the other day:
I'm parsing a file format that contain file system paths installed by the system package manager. Things like space are escaped octally (e.g. \040) in that format. Which I need to decode and then get back to PathBuf for opening those files (I'm checking that package managed files are unchanged).
On Linux that is a non-issue of course (bytes are bytes). But on Windows that would be a problem. Of course you may say, "Linux package manager on Windows? Do you really need to support that?". As it turns out that package manager in question (pacman from Arch Linux) happens to also be used for msys2 on Windows. So I expect there may be users there. No clue how msys2 works though, maybe it uses byte oriented APIs internally, in which case I don't need to care about windows paths I guess (I don't have Windows myself, but it is always nice to not artificially limit your user base).
This section in the documentation https://docs.rs/bstr/latest/bstr/#file-paths-and-os-strings seems to be written before into_encoded_bytes and related functions were added/stabilised. Perhaps the section should be updated and any needed support functions in ByteSlice/ByteVec should be added?
Maybe all that is needed are updated guidelines. Here is an example use case I ran into the other day:
I'm parsing a file format that contain file system paths installed by the system package manager. Things like space are escaped octally (e.g.
\040) in that format. Which I need to decode and then get back to PathBuf for opening those files (I'm checking that package managed files are unchanged).On Linux that is a non-issue of course (bytes are bytes). But on Windows that would be a problem. Of course you may say, "Linux package manager on Windows? Do you really need to support that?". As it turns out that package manager in question (pacman from Arch Linux) happens to also be used for msys2 on Windows. So I expect there may be users there. No clue how msys2 works though, maybe it uses byte oriented APIs internally, in which case I don't need to care about windows paths I guess (I don't have Windows myself, but it is always nice to not artificially limit your user base).