Pre-RFC: Rename Path and PathBuf

[withoutboats]

Thanks for this explanation! I’ve never done significant Java programming, and wasn’t aware it had a similar distinction to ours. (Though I’m guessing their String is more like Arc<str> with automatic cloning, which makes the divide a little bit different from where it is for us).

I can see that it is confusing coming from a language with String/StringBuffer for String in Rust to be more like StringBuffer. Even still I agree with @burntsushi that this difference is narrow enough that the confusion from having both names coexist overwhelms the difference.

[quodlibetor]

You’re correct about Java’s String type being essentially Arc<str>, the discussion of references is much more complex than the discussion of String/str.

I can’t think of any languages that have ever renamed/aliased a fundamental type after they were at Rust’s level maturity (fairly mature and stable), so I don’t know of any history that could help guide the discussion.

[dan_t]

I really don’t like the ‘Buf’ postfix and also don’t consider it that telling after all, because why should these types have a certain postfix giving a hint about their implementation, but types like ‘Vec’ don’t?

For me the type ‘PathBuf’ always felt a bit awkward named and I would have prefered the name ‘Path’ for it and naming the slice in some other way.

[scottmcm]

Another possible direction could be type Substring = str;, to emphasize that you only take the full String if you need it to be the entire string, not just a substring.

(Though I agree the churn is probably not worth it.)

[johnthagen]

I always thought that Rust’s String was named this way in part to match C++'s std::string, since it (unless I don’t really understand how C++ works) matches the same ownership, RAII, and (in C++11) move semantics.

[Ofekmeister]

I also somewhat subscribe to the philosophy that Rust will have warts like these that we just need to live with.

That sentiment makes me incredibly sad.

[derekdreery]

Maybe put something at the bottom of the String docs that says “because this is an owned string that works like a Vec with utf8 checking, [it has been said that a better name might have been StrBuf][some useful link goes here].”

EDIT: something better written than this, but you get the idea…

[rpjohnst]

To the contrary, this seems incredibly valuable to me. Nothing will ever be completely wart-free, so drawing the line where Rust has (not only with strict backward compatibility but also practical backward compatibility wrt churn, community knowledge, documentation, etc) brings benefits far greater than the ability to tweak every “wart” you could ever find.

[bluss]

I don’t know what has happened, maybe I’ve internalized the “buffer” notion of Vec and String. Anyway. From teaching standing point I prefer to tell about Vectors and Strings first and ownership first.

As a purely hypothetical exercise I think the best terms would be something that uses an unmodified noun for the owned type and a “view” name for the view. It makes the connotation of string slices more clear — it’s a view type, it’s got a relation with some owned data somewhere. For consistency reasons, one might prefer either “slice” or “view” in the names here.

Owned type	shared view type
Vector<T>	&Slice<T>
String	&StringView
Path	&PathView
OsString	&OsStringView

Edit: edited view names from snake case to camel case.

[scottmcm]

I just noticed this RFC from 3.5 years ago:

https://rust-lang.github.io/rfcs/0060-rename-strbuf.html

[AndrewBrinker]

Wow, that is pretty short. The discussion is longer though: https://github.com/rust-lang/rfcs/pull/60

[system]

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