Provide UnixPath and WindowsPath (ditto PathBuf) on all platforms

[joshtriplett]

Some applications need to manipulate Windows or UNIX paths on different platforms, for a variety of reasons: constructing portable file formats, parsing files from other platforms, handling archive formats, working with certain network protocols, and so on.

We already have the code in the standard library to manipulate both Windows paths and UNIX paths.

I would propose that we either always support both (as UnixPath/UnixPathBuf and WindowsPath/WindowsPathBuf) and alias one of those to Path/PathBuf, or that we at least extract that code and upload it verbatim as a standard crate in the ecosystem that specifically documents itself as containing the exact code from the corresponding version of the Rust standard library.

I personally think this seems useful enough to include in std, but either solution would potentially work.

cc @sunshowers who mentioned needing this.

[retep998]

How would they interact with OsStr/OsString from std?

[joshtriplett]

@retep998 Interesting question! The non-native path types wouldn't necessarily be compatible with the native OS string types, which would make it difficult to reuse the code between them. Doing this thoroughly might require providing non-native OsString/OsStr types as well. That seems useful as well, though.

(Also, all of these shouldn't take up any space in programs that don't use them.)

[skilly-lily]

There's some precedent here with python's stdlib as well. Python's pathlib implementation allows creation of path objects which only exist ephemerally: Pure Paths, and sub-classed paths which can perform real filesystem operations: Concrete Paths.

That said, the biggest difference between the python pathlib and the proposed suggestion is compile-time safety. Python can just throw exceptions on mismatched OS requests and tell the user to fix it, but in rust, we should be able to have compiler-ensured success on most operations. We should even be able to avoid Result's, in nearly all cases, just like the current Path/Pathbuf (except I/O and string parsing/validating, obviously).

As far as actual implementation goes, Path/Pathbuf are currently implemented using OsStr/OsString, respectively. In any case, either cross-platform OsStr/OsString needs to be exposed, or the top-level implementation of Path/Pathbuf needs another layer of indirection on top of OsStr/OsString to allow cross-platform access.

Based on the above statement, I personally think that this justifies an RFC, or perhaps a small third-party crate proving the concept. If accepted, it would make sense to keep this in std, but other than that there's nothing which forces this concept to only exist in std. The RFC process could additionally answer the OsStr/OsString question.

A potential contributor could definitely make a Proof-of-Concept crate at any time, RFC/this issue aside.

[skilly-lily]

Also, this is being discussed more in the cli-working group repo, although there's a lot of other discussion going on at the same time.

https://github.com/rust-lang-nursery/cli-wg/issues/10

[devsnek]

This would definitely be nice. In Node.js, for example, we provide path.x for whatever you're running on, but we also provide path.win32.x and path.posix.x. It is especially annoying not to be able to access windows path behaviour on wasm targets.

[chipsenkbeil]

@joshtriplett I just published typed-path to provide a 3rd-party option to do this to some degree. Needed this for a server of mine that accepts user paths and parses them agnostic of the compiled platform.

[dsherret]

It would be awesome if there were a way to globally specify which one to use with PathBuf when compiling to wasm32-unknown-unknown. That way in some one time setup code I could swap out the unix implementation with the windows one when I tell the wasm code that I'm running on Windows. This is a huge problem atm with using Rust in Wasm and it's not feasible or practical to get all dependencies to switch away from std::path::PathBuf to something that would provide this behaviour.