parent() returns Some("") for single-component relative paths

[oconnor663]

use std::path::Path;

fn main() {
    println!("{:?}", Path::new("/").parent());  // None
    println!("{:?}", Path::new(".").parent());  // Some("")
    println!("{:?}", Path::new("foo").parent());  // Some("")
}

The latter two cases feel weird to me. Some("") by itself is kind of a contradiction, on the one hand saying "yes there is a parent" and on the other hand returning an invalid path that really means "no there isn't actually a parent." We've also tried to avoid creating empty path components in other cases, like the double-slash case Path::new("a//b").parent(), which returns Some("a") rather than Some("").

For consistency with /, it probably makes sense to have the parent of . be None. For foo I could imagine going either of two ways, either Some(".") or None. If folks agree that one of those options would be nice in theory, then I guess the second question is whether a behavior change here would break backwards compatibility too much to consider doing it. Would it make sense for me to put together a PR and then ask for a Crater run or something like that?

[nagisa]

Technically a parent of . is a .., but we cannot return that due to oversights in the design of the function (returns Path, not PathBuf/Cow<Path>)?

[alexcrichton]

cc @aturon

These sorts of subtle details in behavior of path are notoriously difficult and often have surprising results. One helpful comparison is to see what a bunch of other path libraries do as well in situations like this.

[oconnor663]

Python is inconsistent between os.path and pathlib.Path, so unfortunately "doing what Python does" isn't really an option. The main consistent thing between their two implementations, which is notably different from Rust, is that the parent relationship is circular once you get to the bottom of it. On the question of "is the empty string the parent of anything?" they give different answers. Here's some more detail:

os.path.dirname

os.path.dirname("/") == "/"
os.path.dirname("/foo") == "/"
os.path.dirname("/foo/") == "/foo"
os.path.dirname("") == ""
os.path.dirname("foo") == ""
os.path.dirname("foo/") == "foo"
os.path.dirname("foo/bar") == "foo"
os.path.dirname("./foo") == "."

Looking at the implementation in CPython, it seems to be

1. drop everything to the right of the right-most separator (or just everything, if there are no separators)
2. rstrip any remaining separators off of what's left, unless the remaining string is composed entirely of separators

The "unless" in (2) is how they maintain dirname("/") == "/", though it also has the weird consequence that dirname("//") == "//" and so on.

Summary: not very smart about trailing separators or dots, postpones normalizing things until it needs to, willing to give you an empty string, eventually circular if you call it enough times

pathlib.Path.parent

Path("/").parent == Path('/')
Path("/foo").parent == Path('/')
Path("/foo/").parent == Path('/')
PureWindowsPath("C:\\foo").parent == PureWindowsPath("C:\\")
PureWindowsPath("C:\\").parent == PureWindowsPath("C:\\")
Path("") == Path('.')
Path("").parent == Path('.')
Path(".").parent == Path('.')
Path("foo").parent == Path('.')
Path("foo/").parent == Path('.')
Path("foo/./././").parent == Path('.')
Path("./foo").parent == Path('.')

Pathlib tries to be smarter. It drops all duplicated separators, trailing separators, and single dots when paths are constructed. Unless the path is (or would be) empty, in which case it becomes a single dot.

Summary: smart about separators and dots, aggressive about normalization, never willing to give you an empty string, also eventually circular

[oconnor663]

On the question of returning Some(".") vs None, I can imagine a few different invariants we could decide to maintain:

• If a path exists on the filesystem, and its parent is Some, then its parent exists on the filesystem too. Both sides maintain this. (Though libstd's current behavior violates this.)
• If a path refers (or could refer) to a file, then its parent will always be Some. Only the Some(".") approach maintains this.
• If a path's parent is Some, the parent is a prefix of it. Only the None approach maintains this.

That last invariant, the prefix one, is important for non-empty parents in most cases, since we don't want parent to have to allocate a PathBuf. But in this specific case we can return "." as a &'static Path, so we can get away with breaking it. Would a caller care about getting a prefix back for any other reason?

One possible issue might be if we ever need to support a weird platform where "." is not actually a valid path to "foo"'s parent directory. Though maybe in that case we would define some new per-platform constant, and tweak the definition of parent to say that it might return whatever that thing is?

[oconnor663]

Oh gosh, yet another consideration: Components is aware of leading dots, and because of that the parent of Some ("./foo") is currently Some("."), even though single dots are skipped elsewhere. So we have to choose between "consistency across different forms of the same relative path" and "consistency between the parent method and the components list".

[bluss]

@nagisa We can return Path("..") in particular, just sticking ".." into a static(!).

[nagisa]

@bluss can you return ../../ which is a parent of .. though? and ../../../ afterwards etc.

[jFransham]

Maybe .parent() can return None when there is no meaningful substring parent (because the path is relative), and there could be a seperate method ,relative_parent() (name bikeshedding very welcome) that returns a Cow<Path>?

[oconnor663]

That PR (#40447) cause at least one break in the Rust build itself, noted in the comments there. I might try the "synthetic ." approach at some point, though I'm not sure that will be any less breaky.

[Mark-Simulacrum]

The only thing we can really do is the relative_parent addition, I think, since changing what the existing method returns seems impractical (hard to catch and fix changed uses).