Getting rid of String slices for better ergonomy

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

[jjpe]

@kornel This would be workable, but of course then we need to explain why one literal type allocates while another one doesn’t.

@tibotz As explained before in this thread there are tradeoffs to be made when it comes to string design, if there is an abstraction that lets a programmer have it all, it has yet to be invented.

The string behavior observed in languages such as Java and python (which you seem to be arguing for) is built on the fact that those strings are garbage-collected. Rust has no such concept, and from that basic premise flows a different design. Now, it is possible to abstract over both &str and String with e.g. Cow<str> but that induces a runtime penalty, as explained by an earlier post.

It’s like the opposite of zero cost abstraction

Calls that turn a borrow into an owned value can never be never zero cost. As for the “syntactic overhead”, that’s the point The code is supposed to make the reader aware that expensive operations are happening. Rust has a different niche as a programming language than e.g. Python or Java, and it is designed as such. You wouldn’t want to create a kernel in Python/Java, for example. This has to be as possible in Rust as it is in C/C++, and more so where possible. Trading performance-by-default in favor of convenience seems like the wrong tradeoff for such a language.

A language is all about abstracting things away

I’d say that a language is about abstracting certain things away. What exactly is abstracted by that language depends on the purpose of the language. Rust, for example, is a language that puts performance, safety and concurrency above programmer convenience. When all 4 are possible at the same time, that’s great, and it’ll happily take all 4 into account. But when tradeoffs need to be made, convenience is easily the first thing to go. That makes Rust in a sense a lower level language than Java (at least when it comes to things like strings), and that’s perfectly fine.

[Soni]

that’s funny, I use Rust as a scripting language all the time and I never had an issue with strings.

anyway, you probably want str methods that produce Box<str>.

fn concat(&str, &str) -> Box<str>

this makes str inefficient but easy to use. use String for performance.

Lua makes a similar tradeoff: use … if you want something inefficient but easy to use (well, sometimes this can be more efficient, but it’d need to take an array tbh), use table.concat for performance.

(technically, Rust String provides the worst of both worlds… but it generally works well enough, better than repeated concatenation but worse than table.concat. I don’t think Rust has any APIs comparable to table.concat…)

[notriddle]

I don’t think Rust has any APIs comparable to table.concat…

slice::join?

[H2CO3]

Note that if the RHS is already a string literal, you don’t need to (and for performance and complexity reasons, probably shouldn’t) go through a String buffer. let concatenated = foo + "StringUser" should work fine.

[jjpe]

Agreed, the reason I wrote it that way was simply to demonstrate how String allocation works, which is seen as a papercut by those who want String literals.

[Soni]

That outputs an String not a Box<str>

[CAD97]

And why would you prefer to get Box<str> in this case?

And slice.join("").into_boxed_str() will literally just discard the capacity field in String anyway, as <&[&str]>::join(&self,&str)->String doesn’t over-allocate.

[Soni]

Eh, still dislike it… but then I’m comparing it to Lua, which doesn’t have mutable character buffers.

I like Rust and I generally like how strings work in Rust. But maybe we can simply get rid of String… Lua doesn’t have it.

[ExpHP]

Box<str> is nothing like Lua’s strings, which are more like Gc<str>. You need an entire runtime to make that happen.

Mutating strings is an uncommon need, to be sure (unless you’re actually writing a method like join), but I don’t see why it should bother you so much that the option is there. The borrow checker forbids you from doing anything you’ll regret.

[system]

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