Why does ranging over the Go string "héllo" yield indices 0, 1, 3, 4, 5?

### What the loop actually does When the operand of `range` is a string, the loop does not walk bytes and it does not walk a precomputed array of characters. It **decodes UTF-8 on the fly**. On each iteration it looks at the bytes starting at the current position, works out how many of them form one code point, produces that code point, and advances the position by exactly that many bytes. That gives the two loop values: 1. **First value — the byte offset** at which the current character's encoding starts, counted in the same units `len` uses. 2. **Second value — the decoded code point**, of type `rune`. ### Walking through "héllo" The stored bytes are: `h` at 0; `é` at 1 and 2 (two bytes); `l` at 3; `l` at 4; `o` at 5. Six bytes, five characters. So the loop yields the pairs `(0, 'h')`, `(1, 'é')`, `(3, 'l')`, `(4, 'l')`, `(5, 'o')`. Offset 2 never appears, because it is not the *start* of anything — it is the continuation byte of the accented letter. The gaps are the point. The offsets are not a counter; they are positions in the underlying bytes. A five-character string yields five iterations, but the largest offset can be as high as `len(s)-1` for a four-byte character. ### The three forms of the loop - `for i, r := range s` — offset and decoded code point. - `for i := range s` — offsets only. This is the cheap way to enumerate character boundaries. - `for range s` — neither; useful only to count characters. With one variable you get the **index**, not the value — the same rule as ranging over a slice, and a frequent slip when someone means to iterate characters. ### Why the offset is the useful half Because the offset always lands on a character boundary, it is exactly what you need to slice safely. `s[i:]` is the remainder of the text from that character onwards, and `s[:i]` is everything before it — both guaranteed to be whole characters, unlike an arbitrary numeric cut. Scanning for the position of the last character that fits inside a byte budget is the standard use. ### Contrast with an index loop ``` for i := 0; i < len(s); i++ { ... s[i] ... } ``` This walks **bytes**. Each `s[i]` is a single byte value, and for a multi-byte character you see its pieces one at a time, none of which is a valid character on its own. Both loops are legitimate — byte scanning is right when you are looking for an ASCII delimiter such as a comma or a newline, because UTF-8 guarantees no ASCII byte appears inside a multi-byte sequence — but only the range form gives you characters. ### Invalid bytes Nothing guarantees a string is valid UTF-8. When the decode fails, the loop does not panic and does not stop: it yields **U+FFFD**, the Unicode replacement character, and advances exactly one byte, then tries again. That is why a corrupted string produces a run of replacement characters rather than an error. If you need to know whether the text was valid, you have to check explicitly rather than infer it from the loop. One consequence worth remembering: because U+FFFD is also a perfectly legal character that a string can genuinely contain, seeing one in the output does not by itself prove the input was corrupt — though in practice it almost always does. ### Printing what you get The second loop value is a numeric code point. `fmt.Println(r)` prints a number; `fmt.Printf("%c", r)` prints the character and `%q` prints it quoted. Someone debugging this loop for the first time usually prints the number by accident and concludes the decoding is broken. ### The mental model Read `for i, r := range s` as: *give me each character together with where it starts*. The character is for logic; the offset is for slicing. Once both halves have names, the jumpy indices stop looking like a bug and start looking like the boundary information they are.