Would like path_of

[epage]

Issue by njaard
Wednesday Mar 04, 2020 at 23:47 GMT
Originally opened as clap-rs/clap#1723

---

Use case

It's common to get a filename from clap with value_of_os and its companion values_of_os. You often want to turn it into a Path in order to pass it to std::fs::File::open().

The only way I've been able to find to turn an OsStr into a Path is with Path::new(), which is a bit wordy. Therefor, it'd be nice be able to get Path objects directly.

Proposed solution

It'd be nice if there were a function like Matches::path_of(name: &str) -> Option<&Path> so that you can get a Path in a single function call.

Alternate names for path_of might be the consistent but less concise value_of_path but that somehow reads grammatically different than value_of_os, not to mention being longer. Therefor, path_of sounds better.

Additionally, you'd want paths_of the way there is values_of_os

Hypothetically, one could also make it reject (at get_matches-time) impossible Paths (on Windows, not all Paths are valid).

Alternative solutions

The standard library could get some sort of convenient shorthand for turning OsStr into Path. I think adding the function into clap serves the purpose better because it self-documents better while keeping std clean and explicit.

[epage]

Comment by CreepySkeleton
Thursday Mar 05, 2020 at 07:36 GMT

---

I'm not very excited about adding yet another output format, but we can make it if paths are really so common, perhaps under value_of_as_path and values_of_as_paths names. cc @pksunkara @Dylan-DPC what do you think?

Hypothetically, one could also make it reject (at get_matches-time) impossible Paths (on Windows, not all Paths are valid).

That's definitely up to user. Even Path::from doesn't validate it.

[epage]

Comment by njaard
Thursday Mar 05, 2020 at 19:14 GMT

---

I'm not very excited about adding yet another output format, but we can make it if paths are really so common, perhaps under value_of_as_path and values_of_as_paths names.

CLI tools of course have filenames as a common use case.

That's definitely up to user. Even Path::from doesn't validate it.

Well, I was just speculating, but naturally if the user doesn't want it validated, they could just use value_of_os.

[epage]

Comment by CreepySkeleton
Thursday Mar 05, 2020 at 19:16 GMT

---

Except, what does "valid path" means?

[epage]

Comment by njaard
Thursday Mar 05, 2020 at 19:24 GMT

---

Except, what does "valid path" means?

On Windows, a Path may not contain <, >, |, ", ?, *, and outside of drive letters, : according to Wikipedia. (I don't use Windows)

On Linux, I think there are no restrictions other than of course the null termination.

[epage]

Comment by CreepySkeleton
Thursday Mar 05, 2020 at 19:38 GMT

---

This kind of checking would be largely useless. The os facilities would check it anyway (std::fs::* in Rust), so I don't see the point to check it on our side.

Come to think about it, value_of_as_path is a trivial value_of().map(Path::from); I'm very unconvinced about your proposal, no offense. Let's hear out the other maintainers @TeXitoi @pksunkara @Dylan-DPC .

[epage]

Comment by TeXitoi
Thursday Mar 05, 2020 at 20:12 GMT

---

It would be only me, I'd say no. I'm not really convinced by the added feature.

[epage]

Comment by pksunkara
Friday Mar 06, 2020 at 10:35 GMT

---

It is definitely trivial. I would consider this one of those things where if more people request it, I wouldn't mind adding it.

[epage]

Comment by CreepySkeleton
Friday Mar 06, 2020 at 11:37 GMT

---

@pksunkara Which one? The checking or the conversion?

[epage]

Comment by pksunkara
Friday Mar 06, 2020 at 11:43 GMT

---

Conversion

[epage]

Comment by njaard
Friday Mar 13, 2020 at 22:13 GMT

---

Another compelling argument in favor is that I believe it's more teachable: If a user has an &str, they can pass it directly into File::open, however, OsStr cannot be, it needs to be converted into a Path and not making it easy and automatic acts as another barrier to writing correct code.

[epage]

Comment by CreepySkeleton
Friday Mar 13, 2020 at 22:57 GMT

---

If a user has an &str, they can pass it directly into File::open, however, OsStr cannot be

Good try, but it can 😮

[epage]

Comment by njaard
Wednesday Mar 18, 2020 at 20:17 GMT

---

If a user has an &str, they can pass it directly into File::open, however, OsStr cannot be

Good try, but it can open_mouth

Doh. Yes because File accepts AsRef<Path>, but when one writes basic application code, I think &Path is more common. At least it is for me.

[epage]

Comment by CreepySkeleton
Wednesday Mar 18, 2020 at 23:36 GMT

---

Doh. Yes because File accepts AsRef, but when one writes basic application code, I think &Path is more common. At least it is for me.

Well, the argument was about flattening the learning curve, wasn't it? I've swept through std::fs::* and found that the API uses AsRef<Path> instead of &Path literally everywhere. In fact, you would want to use Path explicitly only when you want to query some property of the Path itself, like extension or is_file.

I see your point about Paths being commonplace, but it could use some acknowledgement. If and when at least two more people come here to ask for it, I'll have become open to accepting such a PR.

[epage]

Comment by CreepySkeleton
Tuesday Jun 30, 2020 at 10:13 GMT

---

Closing as inactive. I don't think this feature is of any use, and, evidently, almost nobody wants it.

[epage]

Comment by Dylan-DPC
Tuesday Jun 30, 2020 at 10:19 GMT

---

Please don't close any issues just because nobody commented they needed it. There could always be a future feature request.