Getting rid of String slices for better ergonomy

[zachlute]

There is a closed PR floating around that goes into detail.

Do you have the link? Would be nice to read through that

I believe this is the PR in question: https://github.com/rust-lang/rust/pull/19612

[soc]

It would be fascinating to give it one more try, combined with a better name like StringBuf…

[matt1985]

Could something like Cow<'a,str> be the default string type?

What would be the problems of making something like Cow<'a,str> the only string type? Aside from backwards compatibility concerns, I mean.

[Tom-Phinney]

How would it work with no_std where no heap allocator is available for creating a copy?

[matt1985]

It would not work,I had not thought about no_std.

There doesn’t seem to be a way to have all of these at the same time then:

1. A string type accessible in no_std contexts.

2. A view into another string.

3. A mutable string type.

4. Having a single string type.

I do not think sacrificing 1 or 2 for 4 would be a good idea.

[bestouff]

I do think that having a unique string type, something like type Str = Cow<'a, str>; would be nice, even if it’s unavailable in no_std.

[birkenfeld]

I do think that having a unique string type, something like type Str = Cow<'a, str>; would be nice, even if it’s unavailable in no_std .

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.

[mbrubeck]

For some historical context: In very early versions of Rust, the equivalent of String was ~str, the equivalent of Vec<T> was ~[T], and for non-slice types, the equivalent of Box<T> was ~T.

Value	Borrowed pointer	Owned pointer
u8	&u8	~u8
str	&str	~str
[T]	&[T]	~[T]

This made the type names more consistent, but their behavior less consistent. For example ~str and ~[T] were growable, just like modern String and Vec, so they had special built-in methods that were not available on their borrowed equivalents. They were also 3 pointer-widths in size, which was inconsistent with other ~T types. And there could be no equivalent of modern Box<str> or Box<[T]>.

Today we have have reduced the number of special built-in pointers, and added library types in their place:

Slice	Borrowed pointer	Owned pointer	Growable buffer
str	&str	Box<str>	String
[T]	&[T]	Box<[T]>	Vec<T>
Path	&Path	Box<Path>	PathBuf
OsStr	&OsStr	Box<OsStr>	OsString
…etc

This reduces language complexity but moves the same complexity into libraries, and it means fewer sigils to remember but more names.

These library types may become more understandable if you consider them all “smart pointer” types. For example String implements Deref<Target=str>, so when you access its contents the relevant type is still str.

[mbrubeck]

If we wanted to make the naming more consistent, perhaps there could be a generic “growable buffer” type, such that String would be renamed to Buf<str> and Vec<T> to Buf<[T]>, etc.:

Slice	Borrowed pointer	Owned pointer	Growable buffer
str	&str	Box<str>	Buf<str>
[T]	&[T]	Box<[T]>	Buf<[T]>
Path	&Path	Box<Path>	Buf<Path>
OsStr	&OsStr	Box<OsStr>	Buf<OsStr>
…etc

But note that a great many of the methods and traits on Buf<T> would vary based on T, so programmers would still need to learn the specifics of individual types like Buf<str> – just not a new name.

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