Getting rid of String slices for better ergonomy

[Centril]

Nowadays we also have Rc<str> and Arc<str> as well as Rc<[T]> and Arc<[T]>.

[mbrubeck]

For another point of comparison, modern C++ has std::string (similar to Rust String) and std::string_view (similar to Rust &str), as well as various other specialized string types.

[djc]

I’m actually a bit skeptic of the claim for better ergonomy here. Yes, the current String vs str disparity has a clear learning curve to it, but I don’t actually find it very hard in practice. (Even if there are still some coercion cliffs in places, but those can just be ironed out over time.)

[cuviper]

The problem is that this doesn’t work as written, it would have to be Str<'a> , and therefore in every struct you currently have an owned String , you introduce a lifetime.

If you know it’s owned, you can use Str<'static>.

[soc]

I think something like

Slice	Borrowed pointer	Owned pointer	Growable buffer
Str	&Str	Box<Str>	StrBuf
Vec<T>	&Vec<T>	Box<Vec<T>>	VecBuf<T>
Path	&Path	Box<Path>	PathBuf
OsStr	&OsStr	Box<OsStr>	OsStrBuf
…etc

would have been extremely nice.

I still have hard time remembering the naming inconsistencies, and I have never found all the various special syntax rules convincing enough to not consider them accidental syntax warts. (E. g. why some types are written lower-case, but others are written upper-case, or why some types have special constructor syntax like [1,2,3].)

Here’s the wish that Rust 2 cleaned this up – of course with the assumption that there would be a rust-fix tool which can translate these differences from Rust 1 to Rust 2 and back. If one didn’t use anything new from Rust 2, the build tool could even automatically translate things back and forth.

[skysch]

I don’t see anything more than a very marginal ergonomic/learning benefit from any of the proposed alternatives. Sure, they’re a bit more streamlined and consistent, but “perfect is the enemy of good.” Beginners will still have to learn what the different terms mean. And they’ll have to learn the reasons that multiple string types exist. (And why that’s the case in almost every language.) That’s unavoidable. Whether you have a convention that “buf” means “growable” or not is largely immaterial. You’ll still be having to teach people when to use StrBuf over OsStrBuf or VecBuf, etc.

And at the end of the day, nobody’s code will even run better. We’d just have a different color bikeshed.

[soc]

I think the ultimate test whether something is a bikeshed is “if we had consistent names, would people argue for making them inconsistent?”, and I think this is clearly not the case.

Every “marginal” inconsistency is yet another papercut – it adds up over time, but is hard to see for people who have adopted Rust a long time ago.

[gbutler]

I think this is clearly not the case.

That’s quite a claim. I can think of a lot of people that would take the opposite position. Different things should be different.

[skysch]

I don’t think it’s totally clear. Someone might be wondering what the relationship between StringBuf and BufReader is, for instance.

If an engineering team decides the build a bridge with steel trusses, it is a given that they need to be painted. And there are lots of different reasons to paint it in different colors. Some colors are better looking, some are safer, some are traditional, some are more memorable. And there’s a lot of worthwhile thought that can go into making that sort of decision. Where it goes off the rails is when the paint-selection commitee goes to the engineering team and suggests the steel beams be substituted for wooden ones.

In that case, we’re talking about breaking Rust’s stability guarantees or performance focus. And I’d argue adding superfluous types to std is similarly questionable.

[kornel]

Cow is probably not as nice as you expect.

It’s a necessary evil for optionally returning owned data, but it has all the downsides of both types it represents. It has a lifetime attached causing borrow checker woes as bad as &str, and it’s larger than String and causes double indirection if you pass it by reference.

Cow<'static> is not any better either. It is a waste of space for every single string in the program to just share string literals, but still much less efficiently than &str.

There was a proposal to hack 0-capacity String to mean it’s a string literal and the data pointer shouldn’t be freed.

[rubberduck203]

I have nearly a decade of experience, and that experience ranges as many languages as years. That includes C, C++, PLCs, C#, Java, F#, Elixir, and more. I understand programming on a deep level. The explicit ownership model of Rust does not baffle me. I have ergonomic issues with strings in Rust.

Please do not dismiss users telling you there are problems with the lack of ergonomics here. We’re not inexperienced folks who just need to learn the concepts. We’re veteran software engineers who are providing feedback about the current APIs.

[djc]

I was not trying to dismiss anything here (and I’m a bit surprised that you would read that into my earlier comment). I’m merely trying to puzzle apart if there is a difference between learnability and usability here, mostly because, as I was saying, I did not find the the String vs str disparity very hard relative to other parts of the language.

I’m curious if those who find String vs str confusing (other than for just the names) also have trouble with Vec vs slice. To me there’s such an obvious parallel here that I find it quite straightforward to use in practice (modulo maybe rough edges like Index into str being on the underlying u8 storage).

[rubberduck203]

My apologies, but it’s not the first I’ve heard someone from the community be dismissive about the ergonomic issues with Strings. The Rust-Lang Twitter admin has even done it to me personally. Anyway, moving on.

I don’t find the types themselves confusing. It makes perfect sense once you’ve got the idea of what slices are. Except maybe, as for why there’s a special type for string slices.

I find there’s an actual usability issue with strings in Rust. For a high level language, I spend 2-4x the amount of effort doing any string processing than I would in other languages, with the exception of C and maybe C++. I know that the language is designed to be very explicit about when you’re allocating a String from a str, but the reverse should be implicit IMO. I find myself consistently surprised, although I shouldn’t be at this point, when the type checker throws a tantrum when trying to pass a String into a function that takes a str.

[scottmcm]

I know that the language is designed to be very explicit about when you’re allocating a String from a str, but the reverse should be implicit IMO. I find myself consistently surprised, although I shouldn’t be at this point, when the type checker throws a tantrum when trying to pass a String into a function that takes a str.

Can you elaborate? str is a DST, so functions cannot take a raw str. Do you mean passing a String to something that takes a &str? Because that’s a different thing than anything about strings – you can’t pass an i32 to something that takes &i32 either.

[kornel]

Would String literals help enough?

This is one obvious ergonomic deficiency, which I think everyone can agree on.

It also makes novice users first encounter with stings based on &'static str, which is sort of an edge case for stings and lifetimes.

[jjpe]

Would String literals help enough?

That makes me think of a similar proposal on one of the rust forums that turned out an April fool’s day joke. So I gotta ask: what would that look like?

As for ergonomics issues: I haven’t seen a concrete example yet in this thread, but the only place where it can sometimes get a little messy for me is when I use the + operator to concatenate a string slice to the contents of a mutable String buffer. Even then it’s just an extra & to first borrow and then force a deref to &str. So the mess mostly looks like this:

// Owned String creation could use literals I suppose, but IMO not big enough to be worth
// arguing over, and there's something to be said for uniformity with other types:
let mut foo = String::from("hello world, "); 

let bar = String::from("StringUser");

let concatenated = foo + &bar; // This is slightly annoying but again not that big of a deal compared to:
// let concatenated = foo + bar;

Those are my biggest annoyances with the String system, so I’m wondering what exactly the big ergonomic issues are, other than the discussion about string names.

[tibotz]

String literal might means that as a beginner you wouldn’t be exposed that much to string slices and you might still be able to produce some code without knowing about slices. You basically smooth the learning curve.

That being said, it can also introduce even more confusion with the current &str literal.

Regarding examples, concatenation is a good example. Also initialisation of struct containing String. I have fair number of to_owned in my code.

[jjpe]

The fact that you need something like .into() or .to_owned() in Rust is not a bug, or even an issue. It’s an explicit design decision to force the user to write an explicit marker where potentially expensive conversions occur. While it might be less convenient to write, I can tell you from experience that it sure is a big help in understanding the performance of code you wrote a year ago, or someone else’s code for that matter.

Similar things happen when you go from a &[T] to a Vec<T>, for example, or when cloning non-Copy values.

Please don’t expect Rust to behave as something as Java or Python. Rust’s memory management fundamentals (i.e. ownership-based) as well as the use cases for the language as a whole are sufficiently different from those languages that expecting this kind of thing to behave similarly is setting yourself up for failure, a lot of anger, or both.

[kornel]

String::from("") is not too bad, but it does make docs a bit more verbose. I fought for changing std HashMap example to owned strings (since that’s the usual/easy way), but extra calls in the examples were a downside.

I’m not sure about the syntax. There is one for Vec, but I don’t see a way to be consistent with it. So maybe S"hello world"?

[tibotz]

I never said to_owned and into shouldn’t exist in general… I’m just saying that I’m doing it a lot to convert from one string type to an other. And Rust memory management itself has nothing to do with having a unified string type.

I really don’t buy the argument “its a really big help the language doesn’t make it convenient so you can understand performance code”. It’s like the opposite of zero cost abstraction. A language is all about abstracting things away. Here most user won’t care whether the string live on the stack or on the heap as long as the compiler chose the right one, make it transparent and allow enough customisation when you actually need it.

I actually think comparing with other language is very relevant because, knowing what the Rust compiler knows, you should be able to make something which is both more convenient and more performant.