RFC: Rename StrBuf to String

[pcwalton]

No description provided.

[alexcrichton]

cc rust-lang/rust#13717

[nrc]

I can't think of a reason to disagree with this, but it seems to go against the grain of existing languages so I would like to understand better the drawbacks for this.

In C++, Java and most other 'static' feeling languages, the default and ubiquitous string type is fixed length and the more flexible, mutable string type has a longer/more complex name and is secondary. Here we propose the opposite. The only advantage I can see is saving a word per string and history. If that is it then +1 to this proposal. Are there other reasons to preference fixed length strings?

[huonw]

Wouldn't DST allow us to have ConstStr { data: [u8] }? (Something like Rc<ConstStr> seems like it might be mildly useful?)

[pcwalton]

In C++, Java and most other 'static' feeling languages, the default and ubiquitous string type is fixed length

By fixed length you mean immutable, right? Not "in the type"?

Also note that in Java String is actually a lang item, java.lang.String.

[bill-myers]

Another option could be to have a much higher level persistent string data structure, such as a variant of https://en.wikipedia.org/wiki/Rope_%28computer_science%29 made with Arcs where nodes could be an enum (discriminating on unused pointer bits) of a tree node, &'static str, 0-7 inline characters, ~str or Arc.

This would basically allow to clone, share, send and concatenate strings freely with constant memory cost and O(1) or O(log n) time cost.

The main issue of this kind of data structure in general is that accessing the kth element requires O(log n) time instead of O(1), but unlike in arrays where it is sometimes the prevalent operation, this is very rare with strings (also because due to UTF-8 it is mostly meaningless), so it could be a good fit.

EDIT: to be clear, the API-level difference is that a solution like this allows to use the same type for both "work in progress" and "finished" strings without catastrophic effects like using 2x memory (using StrBuf for finished strings) or requiring quadratic time for repeated concatenation (using string for work in progress strings).

[huonw]

I would think we still need a contiguous-memory string builder type at some level, but a rope is certainly desirable as a library.

[nrc]

@pcwalton yes, I mean immutable rather than length in the type.

Java's String is in the library, but it is also (iirc) preferenced by the language in certain ways (string literals, concatenation syntax, etc.) that StringBuilder is not. Kind of a tangent, but this kind of half in the library, half in the language is the worst of both worlds IMO.

[DaGenix]

Java Strings are immutable, but I think a big reason for that is so that methods like trim() can just return a slice of the original String without worrying about it getting changed by another operation. Since Rust can freeze the original string when you take a slice, it doesn't have to worry about this particular case.

[pcwalton]

Kind of a tangent, but this kind of half in the library, half in the language is the worst of both worlds IMO.

I don't agree; lang items are really nice for letting us streamline the compiler and language by allowing us to reuse most of the rules for user-defined things in language-defined things. For example, operator overloading used to not be done with lang items, but instead with magic compiler rules; it was a lot simpler when we moved them to be lang item traits.

[nrc]

I think we are in violent agreement and that either I didn't phrase things very well or I don't know my own mind.

The lang items concept works very well I think. To be concrete about something in Rust that I don't like: format_args!, where there is implicit compiler magic rather than a lang item.

In particular with Java Strings, (and I am totally ignorant about the implementation, so I might be wrong) it seems that Strings are special cases rather than having general purpose stuff that uses a lang item type thing. For example, there is no operator overloading for any class except String which gets to overload +, but that is not apparent from the class definition.

[chris-morgan]

• Observation: when ~str and &str were all we had, there was that nice correspondence between growable strings and string slices. It's a shame to be losing it now; there is very high risk of inexperienced developers using the owned one rather than the slice where that is unnecessary (more than is done now).
• At present Str is a trait. What would it become?
• Now, we have ~str -> &str coercion; what happens about that?
• I prefer the name StrSlice to ConstStr; "const" is a term that we shifted away and which is not found elsewhere in the language or standard library (I think). With my background as a Python developer I do not find "const" very meaningful, either (though I do know what it means).

[thestinger]

Observation: when ~str and &str were all we had, there was that nice correspondence between growable strings and string slices. It's a shame to be losing it now; there is very high risk of inexperienced developers using the owned one rather than the slice where that is unnecessary (more than is done now).

There are going to be other string types like one doing small string optimization. It's a bad thing to have one more closely tied to slices than others, because it encourages people to ignore choosing the one that's actually the right tool for the job.

[nrc]

Oh yeah, +1 for StrSlice over ConstStr

[zkamsler]

There is some danger that this change would encourage people to use Str over StrSlice where the latter would be more appropriate, which is quite a lot of places. Some of that can be addressed through documentation and its use in the standard library, but the naming does tend to privilege one over the other.

[nrc]

@zkamsler where would StrSlice be more appropriate? (Genuine question, I have the same gut feeling myself, but can't actually come up with any examples).

[thestinger]

I think the naming we've chosen for arrays is some what arbitrary already (array: [T, ..n], slice: [T], vector: Vec<T>), so I wouldn't really see an issue with doing the same for strings. The dynamically sized version for &Str, Rc<Str> and Gc<Str> could remain the same with the resizeable version having a name like Text. As long as it's easy to search for and there are consistent terms defined and used by the language/libraries then I don't think it would be confusing.

[zkamsler]

@nick29581 In my opinion, a StrSlice (or whatever it is called) would be more appropriate whenever you only need the contents of the string and don't care about modifying it or owning it (or it can be for a known lifetime 'a or they are all 'static strings anyways). That is certainly true for a lot of parameters. You can consider it analogous to where one would use &[T] versus Vec<T>.

[pnkfelix]

I do not mind the spirit that drives this ticket, but I would not r+ the RFC myself until we find a better name for whatever replaces &str. (As in, I think both StrSlice and ConstStr are too long for something that should be easy to write.) If that means choosing a different name for whatever replaces StrBuf in order to free Str back up, so be it.

(On mozilla/rust#13717 I suggested the paired renaming StrBuf/&str => Str/Sym, but that got some push back and really I am not all that wedded to that idea.)

@thestinger 's suggestion of Text/Str is okay except that I'm pretty sure I wouldn't remember which one is which without practice. (That and I might prefer if we reserve Text for a data type that provides proper Unicode grapheme support...)

Has the paired renaming StrBuf/&str => Buf/Str already been considered and rejected? I feel like we must have touched on it during the work week but I'm not sure I see whats wrong with it, beyond Buf being a more general concept than just about utf-8 string buffers?

---

Worst case scenario, of course, is that I will just do use Sym = str::StrSlice in my own code, or whatever, so I am not going to put up too much of a fight.

[alexcrichton]

Some that came up during lunch today. We could call the string type Str and the slice type chars. Something like:

let foo: &'static chars = "test";
let bar: &chars = foo.slice_to(2);
let mut baz: Str = Str::from_slice("test");
baz.push("bar");

let foo: &chars = baz.as_slice();

[pcwalton]

I figured it'd be Chars.

On Thursday, May 1, 2014, Alex Crichton notifications@github.com wrote:

Some that came up during lunch today. We could call the string type Str
and the slice type chars. Something like:

let foo: &'static chars = "test";
let bar: &chars = foo.slice_to(2);
let mut baz: Str = Str::from_slice("test");
baz.push("bar");

let foo: &chars = baz.as_slice();

—
Reply to this email directly or view it on GitHub.<
https://ci5.googleusercontent.com/proxy/V6728timuLIuIylbXsq7kJl5i_F3q19BsfAqgUXF88YjzEXPM1VIuItbLqSic2P0h5GqazrRzmXSS8zV5ANo-M0wZceymn8tH2xKSAI_CHbrQxR6Ms5Jm9MtTkcUlZ9K6W0oGFLfpG8Qc-M_oeIcMgz9VvsqGKig5j40E7Peo8GfoPCKpfTcWBNaIsV5KHR09_UsTy1a2xqg0o5VWRbMHCj0NUzMWKoWst1DiY9o_Age7KLWN4xZfJMVUaidOptthzcGCOJPB8PxkLlo8M_MZmqc-xWj=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNDU5ODMyNCwiZGF0YSI6eyJpZCI6MzExODkzNzV9fQ==--6723c8d94c07c8e1d82dd6bf59db3be12badf681.gif

[thestinger]

@alexcrichton: I don't really like Chars because it's not actually a collection of char, and I think it will cause some confusion about the encoding.

[pcwalton]

It is a collection of chars, just encoded properly. cf. const char * in
C++.

On Thursday, May 1, 2014, Daniel Micay notifications@github.com wrote:

@alexcrichton: I don't really like Chars because it's not actually a
collection of char, and I think it will cause some confusion about the
encoding.

—
Reply to this email directly or view it on GitHub.<
https://ci4.googleusercontent.com/proxy/4plstqVd0suw_gJbpD7Dc4_sSHYg0cS4ye0O7BmVxUbDaxgVQkIjtUZ5PE9HRVThdnOYVr7bE_LJ8g5y3AvaxshIMrItOcDsHjx5HMngXdHCT-1Cc8VCLxmhllVBYw5crsXHhhorrozYqBd4HNuWHbiQ6dFG-vlEd-KCU9r09CkfHsfVoGOxhnfIqMz5x130TP02nw8kypt2BDcx27p3flOHOI_LPbJYrDtKeg2scJfs6kNdEZzu704T0RN9JSuYznNwoCxw2keXpDm3t4Knr1GdoYqJ=s0-d-e1-ft#https://github.com/notifications/beacon/157897__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNDU5ODY3MiwiZGF0YSI6eyJpZCI6MzExODkzNzV9fQ==--5dad7b97e6d58a0f4755c20b9e546d7407bc2cb5.gif

[bstrie]

I don't really like Chars because it's not actually a collection of char

I don't see this as an indictment against Chars, but rather another data point in favor of renaming the char data type to something that isn't actively baffling. :P

[dobkeratops]

if you want people to use a string slice where possible and not a growable string, would you apply the same rationale you are with the sigils (less typing, less cost) and use the smaller,convenient name for the lighter string slice, and keep a longer name for the growable buffer.

so would that suggest plain Str for the immutable string slice (the thing impatient people will prefer to write), and StrBuf for the dynamic resizing buffer. I've always been happy with the name 'buffer' for something growable (and I don't carry any sentimental attachment to C++'s string type either )

[thestinger]

The goal should be to encourage using borrowed slices whenever possible, and StrBuf otherwise. It shouldn't be more convenient to use a non-growable heap allocated string, because conversions are going to cause syntactic and performance (assuming size is passed to deallocate) overhead.

I think either StrVec or Text for the growable version would be fine, but I don't like StrBuf because we're not calling vectors Buf<T>.

[dobkeratops]

yes i realise you'd pass a pointer not an actual allocation around as a temporary. (&Str?)
A difference in name between growable strings and growable vectors seems ok to me, because vectors are different ... a string isn't just a vec of chars, right? StrBuf was a good name IMO.

[thestinger]

A string is just a vector of bytes, enforcing the UTF-8 invariant. The current &str is essentially just a layer around &[u8], and StrBuf just has a private field with Vec<u8>.

[pnkfelix]

I like Str/&Chars (from StrBuf/&str). I would also be happy with Str/&Utf8, if confusion about the encoding is really an issue. But I slightly prefer &Chars over &Utf8.

[nikomatsakis]

+1 for Str / Chars. I agree that it's mildly confusing that Chars is not a newtyped [char], but I don't know that casual users can ever actually tell the difference, apart from the absence of character-based indexing. I don't particularly care about this discrepancy, I think, but in any case, if we did feel the need to resolve it, I like Chars enough that I might prefer to do so by renaming char to codepoint or something like that.

[pnkfelix]

Update: Currently in Rust, &str implements the Index trait, yielding bytes from whatever offset you feed into the index operator. Thus if we did the &str => &Chars renaming on the current rust implementation, you could index into a Chars, but you would not get back a char from it. That may be what bothers @thestinger ; I am not sure. It certainly would bother me.

I believe the plan of record is to remove the impl of Index on &str (or whatever &str is renamed to). If that is indeed the plan, as in, we will not support s[i] for s : &NewBorrowedStrName, then I still support Chars. (And I would hope removing the Index impl would precede a Chars renaming.)

If I am mistaken and this is not the plan, then I retract my support for Chars, and switch it wholeheartedly to Utf8.

[nrc]

I have a strong dislike for String/str and otherwise no real preference. Let me explain about the 'str'/'String' thing.

Basically, I think having a word and an abbreviation of that word as two things is as bad (or even worse) as using the same word. Note that the & does not help disambiguate because &Str is a perfectly valid type.

First off, I think that the fact that there are similar concepts, does not mean we should have familiar names. There is liable to be confusion as to when to use the two different kinds of string, since they both represent an abstract idea of a string of characters. But, they are different and have different use cases and programmers should think of them differently. Therefore, I think it is important that they have different names.

Since str is just an abbreviation for 'string' it is logical to read them as the same word. So, even though they are not ambiguous on paper, in the minds of many users (not all, but many) they will be ambiguous. Put another way, in the formal syntax of the language they are different. In the wider social vocabulary of the language they are the same.

Some concrete examples of why this is a problem:

Learning Rust, a beginner reads a tutorial. Reads such and such string does such and such. Alt-tabs to their editor and needs to type out a string type - "do I need str or String", back to the tutorial. And then its forgotten the next day because this kind of thing does not stick well in the mind.

IRL conversation between devs:
"so this function foo takes a string"
"wait, do you mean a stur string, or a capital ess string?"

Every single time you say string, you will have to disambiguate. Even if you personally maintain a convention that you say "stur" and not string for String, you can't assume others will stick to that convention.

Since I feel like I shouldn't be entirely negative, I would like to vote for (String or Str or str)/(&chars or &utf8). They are not perfect, but they meet my primary criteria of being non-ambiguous.

[lilyball]

Some concrete examples of why this is a problem:

Learning Rust, a beginner reads a tutorial. Reads such and such string does such and such. Alt-tabs to their editor and needs to type out a string type - "do I need str or String", back to the tutorial. And then its forgotten the next day because this kind of thing does not stick well in the mind.

Sounds like a bad tutorial. The best naming in the world won't help a tutorial that doesn't teach the difference between owned strings and string slices. If the user ever questions "do I need str or String" then they haven't properly learned the difference between the two types. This holds true if it's called str/String, it holds true if it's called Slice/StrBuf, this holds true if it's called FordPrefect/ZaphodBeeblebrox.

IRL conversation between devs:
"so this function foo takes a string"
"wait, do you mean a stur string, or a capital ess string?"

Why would anyone ask that? If the second speaker really needs to know the difference, the question is "owned string or slice?"

Every single time you say string, you will have to disambiguate.

Again, why? In most conversational contexts, it doesn't matter. And if it does matter, you'll have to disambiguate even with your proposed String/&utf8. Because if a function takes a &utf8 and I'm speaking conversationally, I'm still going to call it a string. And I dare you to claim that this doesn't hold true for the vast majority of people.

[SimonSapin]

Since I feel like I shouldn't be entirely negative, I would like to vote for (String or Str or str)/(&chars or &utf8). They are not perfect, but they meet my primary criteria of being non-ambiguous.

But these names don’t tell which is which. It could be owned Utf8 and slice &str just as well as owned String and slice &utf8, so everyone will have to just memorize which it is.

[sinistersnare]

There are going to be other string types like one doing small string optimization
-thestinger

If there are going to be multiple string types with multiple purposes, maybe having str as the lowest common denominator string type to build other string types off of it, starting with BaseString and mabye later add SmallString, SecureString, etc.

[nrc]

@SimonSapin I'm not saying they are perfect, just that they are better than str/string. In the chars/utf8 case you have to memorise that two different words have two different meanings (and you are right, there is no indication of the word-> meaning mapping). In the str case you have to memorise that the same word has two different meanings depending on how it is spelt (and again, there is no indication of word->meaning).

[Valloric]

I have a strong dislike for String/str and otherwise no real preference. Let me explain about the 'str'/'String' thing.

Basically, I think having a word and an abbreviation of that word as two things is as bad (or even worse) as using the same word.

Note that there's precedent for this: Java has int/Integer and it's worked fine there.

kballard and SimonSapin have also brought up good points. I'd like to add that utf8 can't be the slice name with String/Str/str as the owned string because it implies that the owned string isn't utf8. And when the user realizes that both must always be utf8, the first question that will come to mind will be "so why is one of them called utf8 over the other?"

chars I've already ranted against; I'll quote myself below:

"chars" reads like "sequence of chars", which the type isn't. Seriously, let's not even consider using chars without renaming char. We can't have a type that's a plural of a different type and yet isn't a sequence of the singular. That just makes no sense whatsoever. There isn't a person on this planet that when told Rust has types char and chars wouldn't think that chars contains several chars.

I don't think anyone is saying that str/String is the perfect option, just that it's the one that's least shitty.

[Valloric]

In the str case you have to memorise that the same word has two different meanings depending on how it is spelt (and again, there is no indication of word->meaning).

@nick29581 IMO it's very easy to understand which type stands for what in str/String because the shorter & non-capitalized name is obviously the less "powerful" one. If the user is aware that Rust has two concepts for strings, one that's a slice and immutable and the other which is a mutable buffer (and has all the functionality of the slice plus more), then mapping those to the names is obvious.

[nrc]

@kballard I assume the tutorial_does_ explain the difference. The reader has to understand and memorise the difference. I posit that understanding and memorising that difference is easier if there are different words, not just different to write, but different to think. That is, I believe life is easier if it is StrBuf/str or zaphod/ford, and harder if it is String/str.

I disagree on the conversational point. People (generally) use the language they program in as the language when discussing the program. Even where the word can't be pronounced - I hear "twiddle T" more often than "unique pointer to T", and so forth.

I think you are probably right that people will prefer 'string' to 'you tee eff ate'. So I guess I should prefer chars and maybe people will use that. I think that there is a level of formality between conversational (where you would use 'string' and 'number') and totally precise (where you would use 'you 32' and 'you tee eff ate'). I think it is worthwhile having (mostly) unambiguous language for that.

[lilyball]

The reader has to understand and memorise the difference.

That's true no matter what the names are. I believe that naming one after the word "string" and the other after anything else will lead to confusion. For example, as @Valloric says, if the slice is called &utf8 then this suggests that String is not UTF-8, and when the reader discovers that, in fact, it is, this will lead to confusion. "So wait, they're both UTF-8? And they're both strings? So why is one called String and the other called utf8?".

I posit that understanding and memorising that difference is easier if there are different words, not just different to write, but different to think.

As I stated above, regardless of what you name them, people will still think of both as strings. One is an "owned string" and the other is a "string slice". Just as how Vec<T> is an "owned vector" and &[u8] is a "vector slice".

I disagree on the conversational point.

How do you pronounce &[T]?

I certainly don't pronounce it "amp left-bracket tee right-bracket". I usually just say "vector", and if I feel like I need to distinguish ownership then it's "vector slice" or just "slice". Similarly, I pronounce Vec<T> as "vector", and if I need to distinguish ownership then it's usually "vec", although with ~[T]'s deprecation I'm more likely to start saying "owned vector".

So I guess I should prefer chars and maybe people will use that.

chars is the absolute worst idea put forth in this entire thread as the name for this type. It is incredibly misleading as to the nature of the type, conflicts with the meaning of the existing char type, and is just generally wrong. I am not saying this because I want to be mean, I am saying this because I want to stress how much of a mistake it would be to use that name.

I think that there is a level of formality between conversational [...] and totally precise [...]. I think it is worthwhile having (mostly) unambiguous language for that.

Do you disagree that the important distinction at this point between the two types is one of ownership? Because once you've proceeded past the informal "call them both 'string'" stage, what you need to do is distinguish which is the owned value and which is the borrowed value. We already have the proper terminology for that distinction, and as I talked about earlier, that terminology ("owned" vs "slice") is how I use to talk about both strings and vectors in any situation where it matters.

If you do agree that the important distinction at this level is ownership, then the actual type names shouldn't be important for this level of discourse as you're still not actually using them.

[nrc]

@kballard I fear we will not be able to reconcile our points of view. The trouble is that we both have valid points, but we disagree on which has the higher priority and I think that is very difficult to argue.

I agree chars is a bad name, but I prefer it to String/str.

To answer your questions. I pronounce &[T] as 'bracket tee' or where I need to disambiguate the ownership 'and bracket tee'. I pronounce Vec<T> as 'vec tee`.

I think that ownership is one difference. It is also important to know that StrBuf is growable and str is not and that str has the same physical size as its logical size, whilst StrBuf might include spare capacity.

Also, you can have a borrowed reference to a StrBuf, so relying purely on the ownership to disambiguate is not enough. (of course a borrowed reference to a StrBuf is not a slice, but I think that is more reason to disambiguate them).

[lilyball]

To answer your questions. I pronounce &[T] as 'bracket tee' or where I need to disambiguate the ownership 'and bracket tee'. I pronounce Vec as 'vec tee`.

I was not expecting that. I think this explains a lot about why we disagree.

It is also important to know that StrBuf is growable and str is not

Only if there's an owned, non-growable string type that is in common usage. ~str is deprecated in favor of StrBuf (although we haven't expunged it from the libraries yet). Once we have finished that transition, I would expect anyone who hears "owned string" to think of StrBuf and to not consider ~str.

Also, you can have a borrowed reference to a StrBuf, so relying purely on the ownership to disambiguate is not enough.

Sure, but that's an uncommon type. If I really need to talk about it, I'll just be precise ("amp stir buff", or "reference to stir buff", etc).

In general, when talking conversationally about types, the context is the types that are in common usage in the code you're talking about. Once we've finished transitioning from ~str to StrBuf (or whatever its name becomes), the term "owned string" will come to unambiguously mean StrBuf. And if you get to the level where you do need to reference uncommon types, or need to clarify what "owned string" means, you can start talking precisely using the real type names, e.g. "twiddle stir" if you mean ~str, "stir buff" if you mean StrBuf, etc. And at this level, as long as the names are not homophones (which "stir" and "string" are not), then it doesn't matter how close or far apart the names are.

---

I think you are right that we will never reconcile our points of view. So obviously one of us has to give (or be overruled).

I would urge you to consider backing down. If you read this entire thread and all of the discussion in other places, I think you'll find that you are in the significant minority in your opinion. The most common opinion here is that String/&str is the best proposed solution. It may not be perfect, but it's better than anything else that has been suggested.

[nrc]

@kballard I didn't mean to compare StrBuf to ~str when talking about growability and capacity. I meant that StrBuf has these properties and &str does not (as well as the ownership differences). So, I don't worry that people will mistake 'owned string' for anything other than 'StrBuf', but I do worry that if talk about 'owned string' vs 'borrowed string' then users might overlook the other differences.

[lilyball]

I don't worry that people will mistake 'owned string' for anything other than 'StrBuf', but I do worry that if talk about 'owned string' vs 'borrowed string' then users might overlook the other differences.

I'm not sure what you mean. If you expect people to understand that the phrase "owned string" is a reference to StrBuf, then why would you expect people to overlook the fact that StrBuf is growable and has capacity? It seems to me that the phrase "owned string" no more serves to overlook that than the phrase "stir buff" does.

[bstrie]

If the two camps boil down to the following:

1. Both types must contain some variant of the word "string" to convey their close association.
2. Both types must not be an expansion and abbreviation of the same word.

Then the only hope of reconciliation is to agree to give one of the types a compound name. Something like StrVec (or, hilariously, StrBuf) for the growable one, or StrView for the slice. Either way, there's no use in arguing further in this RFC, as we know who is backing which proposal. Take further arguments to private chat, for the sake of all our inboxes.

[liigo]

I vote +1 for &str / String.
Java has int / Integer, float / Float too, it's OK. Rust already has unsafe
/ Unsafe.
2014年5月14日 上午8:40于 "Ben Striegel" notifications@github.com写道：

If the two camps boil down to the following:

1. Both types must contain some variant of the word "string" to
   convey their close association.
2. Both types must not be an expansion and abbreviation of the same
   word.

Then the only hope of reconciliation is to agree to give one of the types
a compound name. Something like StrVec (or, hilariously, StrBuf) for the
growable one, or StrView for the slice. Either way, there's no use in
arguing further in this RFC, as we know who is backing which proposal. Take
further arguments to private chat, for the sake of all our inboxes.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/60#issuecomment-43030565
.

[ftxqxd]

It makes sense to me for strings to be named similarly to arrays/vectors: &[T] is a slice and Vec<T> is a growable vector, &str is a string slice and String (or maybe Str) is a growable string. This means that types such as ~str (and, with DST, Rc<str> and friends) would still exist (but perhaps not be used) in the same way that types like ~[T] (and, with DST, Rc<[T]) exist (although are discouraged). StrVec instead of String/Str would also be acceptable.

Pronunciation is something I’m unsure about, but I pronounce &[T] as “slice”, &str as “string slice”, and Vec<T> as “vec T”. Personally I think that how code is spoken is unimportant (do people complain about not being able to pronounce such characters as { and ~?)

(IMO, in a perfect world string literals would also mirror arrays/vectors — &"string" would be of type &str. But that is not a matter for this RFC.)

TL;DR: String/&str. Consistency > pronunciation.

[liigo]

The most common used string type should be named using the word "string",
or its variant, but not a combination(such as strbuf).

[pczarn]

A string contains text. Consider renaming the string slice type to &text in addition to any of Str/String/StrBuf.

Otherwise, +1 for String/&str

[alexcrichton]

We decided in today's meeting to accept this modified version of this RFC.

[fommil]

@netvl <*> is "ap" as in "apply". \/ is "disjunction". |+| is "append". However many people add a little bit of fun to the symbols and say "sad picachu", "angry rabbit", and "TIE fighter", respectively.