Path::file_name and Path::file_stem shouldn't treat backslashes as part of the file stem

[Boscop]

Why do Path::file_name and Path::file_stem treat backslashes as part of the file stem? (On Windows.)

The file stem should not include the folders of the path and \s, only the final file name's stem.

use std::path::PathBuf;

fn main() {
    let p = PathBuf::from(r"a\b\c.ext"); // inspired by a real use case with relative paths on windows
    println!("file_name {:?}", p.file_name());
    println!("file_stem {:?}", p.file_stem());
}

https://play.rust-lang.org/?gist=15996188fbddf77e28dba123495a47ac&version=stable&mode=debug&edition=2015
prints:

file_name Some("a\\b\\c.ext")
file_stem Some("a\\b\\c")

should print:

file_name Some("c.ext")
file_stem Some("c")

just like it does with forward slashes.

Btw, for comp in p.components() { println!("{:?}", comp); } prints only Normal("a\\b\\c.ext").
https://play.rust-lang.org/?gist=b9732062b47e5959b4c4221cd39e421a&version=stable&mode=debug&edition=2015

---

Btw, is it related to this? #29008

---

EDIT: I forgot to mention that I'm compiling to wasm32-unknown-unknown.
My yew frontend deals with windows paths coming from my sqlite db (song files).
And in the frontend I need to extract the file_stem from windows paths.
It works correctly if I replace \ by / before calling Path::new(&path).file_stem().map_or_else(|| "".into(), |x| x.to_string_lossy().to_string()), but thats a hack :/

What's the recommended way to handle paths in a cross-platform way?
("cross" in the sense of "cross-compiling", but at runtime. Handling Windows paths on wasm32-unknown-unknown with something like std Path. Similarly when e.g. generating Windows bat scripts from a Rust executable running on linux, that needs std Path to interpret \ as a component separator..)

[kennytm]

… since the same wasm binary could be run on multiple platforms, this would require wasm's Path implementation to detect at runtime what platform it was runnning in and choose the path separator appropriately (a backslash must not be treated as a separator on Linux for instance). But this doesn't make sense with a browser host. Perhaps just stub out the entire Path implementation to avoid misuse?

[Boscop]

What do you mean by "stub out"? :)

It shouldn't try to detect the platform. But there should be a type like std's Path but for handling Windows paths with backslashes when the executable is running under linux or wasm32 but specifically needs to handle Windows paths (i.e. that type should always interpret \ as path component separator unconditionally, as with std's Path when target is windows).
E.g. the type could be called WindowsPath.

[kennytm]

What do you mean by "stub out"? :)

Like these.

rust/src/libstd/sys/wasm/fs.rs

Lines 258 to 260 in 6a2c97c

	pub fn unlink(_p: &Path) -> io::Result<()> {
	unsupported()
	}

It shouldn't try to detect the platform.

The point of Path is it interact with the system (e.g. opening or moving a file), so I don't see why not.

The platform-independent WindowsPath could live in crates.io (similar to relative_path).

[ChrisDenton]

Given the above discussion I'm closing this in favour of #66621, which I think would provide a solution to the problem. But if I'm wrong then please tell me and I'll be happy to reopen.