Any chance PathBuf could be renamed?

[gkoz]

This names seems foreign in Rust. It has no relation to BufReader and the company; none of the other owned types that I know of are suffixed with Buf. It’s likely to confuse newcomers.

One alternative is to rename PathBuf -> Path and Path -> PathSlice while either keeping AsPath or making it AsPathSlice. This relies on the users knowing what a slice is opposed to a Buf.

Another possibility is PathStr and PathString.

This got me thinking… Is PathBuf sufficiently different from OsString to be a separate type? What if there just wasn’t a PathBuf? Or would this not play well enough with the Deref convention? Nah, that’s silly…

[tbu]

&PathSlice does not read so nice for me.

[dan_t]

I think the first question is: which of the two should be the nicer readable type?

I consider it somehow wrong, that now the type for holding paths in data structures and returning them by value is now ‘PathBuf’, instead of previously ‘Path’.

So all data structures and also somehow all APIs will have to pay this price.

I don’t see a lot of APIs having to use ‘PathSlice’, because for arguments ‘AsPath’ can be used, and ‘PathSlice’ will most likely be used inside of functions, so the “uglier” name IMHO should be used where it’s more hidden from the API user.

[tbu]

I consider the current Path to be the type that is more important as normally I try to avoid allocations, and PathBuf goes right against that principle, needing one allocation per instance. I’d argue that most of the time you’ll be passing the current &Path around.

[gkoz]

[quote=“tbu, post:4, topic:1673”] I’d argue that most of the time you’ll be passing the current &Path around. [/quote]Wouldn’t many of those cases actually use &P where P: AsPath?

[tbu]

I think that’s just a way for the standard library to overload some file-related functions such as open so you can call them with strings as well. The &P where P: AsPath needs generics for every function that takes a path.

[gkoz]

I’d expect a lot of public APIs, not just libstd, might benefit from substituting &P: AsPath for &Path. It’s not only strings, but OsString as well.

Question is, does less typing (&Path vs &PathSlice) trump naming consistency (a confusing PathBuf vs Path)?

Leaving AsPath unchanged when Path becomes PathSlice would be an inconsistency too though…

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.