Tracking Issue for `fs_native_path`

[ChrisDenton]

Feature gate: #![feature(fs_native_path)]

This is a tracking issue for a new NativePath type that allows users to pass paths more directly to system APIs. This will enable third party crates to implement and experiment with their own path types without having to go through std::path::Path encoding.

Public API

// std::path
pub struct NativePath(_)
pub trait AsPath: Sealed { }

impl<P: AsRef<Path>> AsPath for P { }
impl AsPath for &NativePath { }

// std::os::unix::ffi
pub trait NativePathExt: Sealed {
    fn from_cstr(cstr: &CStr) -> &NativePath;
    fn into_cstr(&self) -> &CStr;
}

// std::os::windows::ffi
// This currently uses a bare `u16` slice but in the future this could perhaps be a `WStr`.
pub trait NativePathExt: Sealed {
    fn from_wide(wide: &[u16]) -> &NativePath;
    unsafe fn from_wide_unchecked(wide: &[u16]) -> &NativePath;
    fn into_wide(&self) -> &[u16];
}

// This also changed the public signature of fs functions.
// Before:
pub fn create_dir<P: AsRef<Path>>(path: P) -> Result<()>
// After:
pub fn create_dir<P: AsPath>(path: P) -> Result<()>

Steps / History

• Implementation: Implement fs_native_path #108981
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• The possibility of a Windows equivalent for CStr.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[tbu-]

This needs a way to ensure that there are no internal null UTF-16 code units on Windows, the currently proposed API doesn't do that, as far as I can tell.

[ChrisDenton]

That's why there's both a from_wide and a from_wide_unchecked (which is unsafe). The former checks for nulls but the latter doesn't.

[tbu-]

What does from_wide do when there are internal NULs? Panic?

If that's proposed, I'd think that returning a Result<…> would be more appropriate, like with CStr::from_bytes_with_nul.

[bardiharborow]

@rustbot label +A-io +A-filesystem +A-ffi