path empty

[jesse99]

In porting my code over to the new Path struct(s) there are a number of places where I wanted to see if a path was set. For now I am using str::is_not_empty(some_path.to_str() which I am not crazy about because it's going to allocate a string and, more importantly, because I'm not sure that ~"" will be round trippable for all file systems.

Note that boost file system has an empty method for just this purpose.

[graydon]

Should Path("/") be considered empty, on unix? How about Path("C:\\") on windows? I'm asking because, to some extent, "empty" is a concept that doesn't really apply to paths-as-a-whole. Paths have components (which there might be zero of) plus possibly a root, of various forms.

The structure holding Path is meant to be inspected directly if you like, so p.components.len() == 0 might tell you what you're interested in. Is that what you want to test though? Or only if it would literally evaluate to the empty string?

[jesse99]

I'd say the use case is the conversion of a string to a Path where the path is supposed to point to something that may or may not exist. These will often come from a config file or command line so there is a desire to do some preflighting or asserts to make sure that the path is sane. Perhaps the thing to do is provide some sort if is_well_formed method that checks for one or more components plus no bad characters for the current file system (WIndows, at least, has a lot of these).

Regardless I would like a more visible abstraction than checking that components is non-empty. Or alternatively just fail if from_str is called with something not well formed.

[jesse99]

If from_str does fail there still needs to be a way for users to test paths so that they can error out gracefully, and error out early, instead of trundling along until the code finally tries to use the bad path.

[graydon]

non-critical for 0.6, de-milestoning

[bstrie]

@jesse99 Would having from_str return an Option be acceptable, where None is returned if the path doesn't exist?

[msullivan]

Do we want to have a notion of an "empty" path build into Path, or should we use Option<Path> for this?

[flaper87]

visiting for triage.

@kballard you know Path better than me. Do you have something to add here?

[lilyball]

I do not believe that we should support the notion of an empty Path. We can already express this with Option<Path>. The path module treats Path::new("") the same as Path::new(".") (for both PosixPath and WindowsPath), and I think that's useful behavior.

[flaper87]

@kballard thanks for your input.

I'll close this bug based on the feedback provided in the previous comments. Feel free to re-open if you think this could be useful.