Pre-RFC: Rename Path and PathBuf

[aturon]

Guarantees	“Slice” Variety	“Owned” Variety
UTF-8	str	StrBuf
C-compatible	CStr	CStrBuf
OS-compatible	OsStr	OsStrBuf
System path	Path	PathBuf

This is one of my big regrets about how 1.0 turned out, and I’d much prefer what you propose. I think such a scheme would go some distance to mitigate the concern that “Rust’s string types are really complicated”.

I wonder how feasible it would be to “change” this by essentially making String an alias for StrBuf, providing a rustfix that makes the adjustment, and leaving it at that for some time – i.e., not deprecating near-term. That would allow the newer name to percolate through the ecosystem without waves of warnings, etc. And people are going to be running rustfix to move to the next epoch anyway. At some distant point in the future, we could eventually deprecate the original name.

cc @nikomatsakis, @withoutboats

[AndrewBrinker]

If the change is being considered, this is certainly the naming scheme I would prefer. I suggested the smaller change initially because I figured there’d be a desire to minimize the scope of the change. But hey, the path of non deprecating and using rustfix to move people over seems pretty appealing, and then you don’t have to worry about the size of the change as much.

[nikomatsakis]

I too prefer this naming scheme. I worry mildly about the “deprecation” of existing documentation and so forth, but a soft deprecation scheme helps here.

[petrochenkov]

I don’t know how feasible the change is, even without deprecation, but it would also be a nice opportunity to finally move str from the language to libcore and rename it to Str.

[withoutboats]

Maybe I’m just used to current names but I think this would be more confusing.

• IMO String et al are more accessible names than StrBuf et al. I know a part of the idea is to “make it clearer” than String has a backing vector, but I don’t think putting Buf in the name makes things any clearer in the same way that non-elided lifetimes don’t make things clearer for new users.
• The mixed documentation would cause a significant amount of confusion, enough that I think it overwhelms the difference between which of these is better.

Maybe I’m just missing the argument.

[rpjohnst]

I think there’s a lot to be said just for the name String. It’s the first thing anyone is going to reach for, and while that does tend to throw them head-first into the &str/String distinction, that’s also a very good motivation for ownership, and not something that would be solved by renaming String anyway.

Keeping the name String around and yet trying to get everyone to use StrBuf will introduce needless confusion on top of this. (“what’s the difference between String and StrBuf? it’s not like Java String/StringBuilder? what’s this third type &str?”) And since we can’t actually remove String without an absolutely earth-shaking epoch, that confusion would likely remain forever.

I don’t think the benefits really outweigh the drawbacks here.

[quodlibetor]

• IMO String et al are more accessible names than StrBuf … I don’t think putting Buf in the name makes things any clearer in the same way that non-elided lifetimes don’t make things clearer for new users.

FWIW I (working with mostly mid- to senior- mostly-java engineers) pretty much always explain String with a sentence that is almost exactly “String is StringBuffer, and str is String”. When working with Python or JS folks the explanation is significantly more wordy, but it always includes something like “internal buffer vs is immutable”.

In emphasizing the internal properties of the types it de-emphasizes the owningness of them. The fact that you can return a String/StrBuf from the function that you created it in is at least as important of a property as the fact that it is growable.

I continue to think that StrBuf is easier to teach – as another example, the way that operators work makes more sense in the context of items that have buffers.

I’m glad that I’m not responsible for making any decisions that have to do with whether that benefit outweighs ecosystem doc-churn.

[burntsushi]

I continue to think that the change does not outweigh the churn this will cause. Imagine new Rust programmers learning about String/str from the book, and then going and seeing StrBuf/str in actual code everywhere that has gone through rustfix. If the String/str naming is already proving difficult to grasp, then changing the name will only make it harder. I concede that “harder” is temporary, but I feel like the length of time is “until the second edition of the book” comes out, which feels like a really long time to me.

I think this is something we should just live with.

[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.