Change:
The codepoint iterator is not mentioned in The use of in is not particularly idiomatic; since is at the 'top level' taking a directly is fine; being generic over is better when it may be expensive for the user to get to a , e.g. if the string data is inside something If the user has and wants to call , they're forced to allocate storage to store the 's of each element, which can be arbitrarily expensive (they may have a lot of s); gets around this since it can be called with or . (FWIW, this is actually still true for functions taking iterators, even though one can sometimes to get a . If you have a , there's no way to convert that into a without collecting into a temporary data structure.)
What's the difference between and ? Such a unicode newbie :frowning:
There's 3 basic levels of unicode (and its encodings): code units, the underlying data type used to store everything code points/unicode scalar values () graphemes (visible characters) For UTF-8, like Rust's strings, the code units are bytes (), the other two are independent of the encoding format. Code points are the letters and combining characters, and graphemes are sequences of codepoints that make up a single visible entity. consider: It is 45 bytes in UTF8, 26 codepoints but only 7 visible characters. The full breakdown is: That is, each little diacritic/combining character is its own codepoint, but sequences of them are rendered together as a single visible unit. (NB. they aren't always separated, there are some precombined characters like which can be either one (U+00E4) or two codepoints (U+0061 U+0308).)
Ahhh gotcha. When would you prefer over ? Or is it just that I mentioned two out of the three?
If possible, text should be treated as a black box chunk of memory that can only be read/written (not iteration) and reencoded (almost always , but preferably a library would do this for you). It's hard to handle arbitrary text semantically accurately, even just splitting words is hard/impossible. Obviously it isn't always always possible to avoid, e.g. an application may wish to be converting textual source code into machine code (but who would do that in Rust anyway? ;P ), in which case it's whatever makes sense for what it's doing. That compiler example probably wants s (since the input is very structured); text editors and text rendering libraries would want to be handling graphemes on some levels and code points on others. But yes, it's mainly that you mentioned only 2 of 3.

Discussion:
## Generic functions <del> To write a function that's generic over types of strings, use [the `Str` trait](http://doc.rust-lang.org/std/str/trait.Str.html): </del> <ins> To write a function that's generic over types of strings, use `&str`. </ins> ```{rust} <del> fn some_string_length<T: Str>(x: T) -> uint { x.as_slice().len() </del> <ins> fn some_string_length(x: &str) -> uint { x.len() </ins> } fn main() {

let s = "Hello, world".to_string(); <del> println!("{}", some_string_length(s)); </del> <ins> println!("{}", some_string_length(s.as_slice())); </ins> } ``` Both of these lines will print `12`. <del> The only method that the `Str` trait has is `as_slice()`, which gives you access to a `&str` value from the underlying string. </del> ## Comparisons To compare a String to a constant string, prefer `as_slice()`...

character can be a variable number of bytes. This means that you have to iterate through the characters anyway, which is a O(n) operation. <del> To iterate over a string, use the `graphemes()` method on `&str`: </del> <ins> There's 3 basic levels of unicode (and its encodings): - code units, the underlying data type used to store everything - code points/unicode scalar values (char) - graphemes (visible characters) Rust provides iterators for each of these situations: - `.bytes()` will iterate over the underlying bytes - `.chars()` will iterate over the code points - `.graphemes()` will iterate over each grapheme Usually, the `graphemes()` method on `&str` is what you want: </ins> ```{rust} <del> let s = "αἰθήρ"; </del> <ins> let s = "u͔n͈̰̎i̙̮͚̦c͚̉o̼̩̰͗d͔̆̓ͥé"; </ins> for l in s.graphemes(true) { println!("{}", l); } ``` <ins> This prints: ```{notrust,ignore} u͔ n͈̰̎ i̙̮͚̦ c͚̉ o̼̩̰͗ d͔̆̓ͥ é ``` </ins> Note that `l` has the type `&str` here, since a single grapheme can consist of multiple codepoints, so a `char` wouldn't be appropriate. <del> This will print out each character in turn, as you'd expect: first "α", then "ἰ", etc. You can see that this is different than just the individual bytes. Here's a version that prints out each byte: </del> <ins> This will print out each visible character in turn, as you'd expect: first "u͔", then "n͈̰̎", etc. If you wanted each individual codepoint of each grapheme, you can use `.chars()`: </ins> ```{rust} <del> let s = "αἰθήρ"; </del> <ins> let s = "u͔n͈̰̎i̙̮͚̦c͚̉o̼̩̰͗d͔̆̓ͥé"; for l in s.chars() { println!("{}", l); } ``` This prints: ```{notrust,ignore} u ͔ n ̎ ͈ ̰ i ̙ ̮ ͚ ̦ c ̉ ͚ o ͗ ̼ ̩ ̰ d ̆ ̓ ͥ ͔ e ́ ``` You can see how some of them are combining characters, and therefore the output looks a bit odd. If you want the individual byte representation of each codepoint, you can use `.bytes()`: ```{rust} let s = "u͔n͈̰̎i̙̮͚̦c͚̉o̼̩̰͗d͔̆̓ͥé"; </ins> for l in s.bytes() { println!("{}", l);

This will print: ```{notrust,ignore} <del> 206 177 225 188 </del> <ins> 117 205 148 110 204 142 205 136 204 </ins> 176 <del> 206 184 206 </del> <ins> 105 204 153 204 </ins> 174 <del> 207 </del> <ins> 205 154 204 166 99 204 137 205 154 111 205 151 204 188 204 169 204 176 100 204 134 205 131 205 165 205 148 101 204 </ins> 129 ```