In Go, what does range yield for a slice, a map, a string, and an integer?

## What range actually gives you `range` is a clause on the `for` statement, and it is the only loop form in Go that produces values for you. The shape of what it produces changes with the operand, which is why saying "range gives you the index and the value" is only a quarter true. ### Over a slice or an array ```go for i, v := range names { // i is an int index, v is a copy of names[i] } ``` The first value is the `int` index, starting at 0. The second is a **copy** of the element, assigned fresh into `v` each iteration. Ranging over an array value rather than a slice behaves the same way from the body's point of view. ### Over a map ```go for k, v := range counts { // k is the key, v is a copy of the value stored under it } ``` You get key and value. The **iteration order is not specified and is deliberately randomised** by the runtime, so two runs over the same map can visit entries in different orders. This is not an accident to be worked around; it exists so that programs cannot accidentally depend on an order the implementation never promised. If you need deterministic output - writing a CSV report, say - collect the keys into a slice, sort them, and range over the sorted slice. ### Over a string ```go for i, r := range line { // i is the byte offset where r begins, r is a rune (int32) } ``` A Go string is a sequence of bytes, conventionally UTF-8. Ranging over it decodes one UTF-8 sequence per iteration: the second value is the code point as a `rune`, and the first is the **byte offset** at which that code point starts - not a character counter. For pure ASCII the two coincide, which is exactly why the difference bites only when real user data shows up. Indexing a string with `line[i]` instead gives a single `byte`, which is a different thing again. ### Over an integer ```go for i := range 5 { // i is 0, 1, 2, 3, 4 } ``` Since Go 1.22 the operand may be an integer. The loop yields a **single** value counting from 0 up to n-1, and taking two variables does not compile. If `n` is zero or negative the body never runs. This form replaces the boilerplate `for i := 0; i < n; i++` when the counter is all you need, and `for range n { }` with no variable is the clean way to repeat something n times. ### The one-variable and zero-variable forms Every range form lets you take fewer values than it offers. With one variable you get only the first: the index for a slice, the key for a map, the byte offset for a string, the counter for an integer. With none at all - `for range x { }` - you get the iterations and nothing else, which is how you count entries or simply repeat. There is a small trap here for people arriving from Python or JavaScript, where `for x in xs` binds the element. In Go, `for x := range xs` over a slice binds the **index**. Writing `for _, v := range xs` when you want values is the habit to build. ### Unused variables are a compile error Go rejects a declared-and-unused local variable, and range variables are no exception: `for i, v := range xs` where `v` is never read does not compile. Use the blank identifier `_` for the position you do not need. That is why so much real Go reads `for _, row := range rows`. ### Practical shape in a batch job A job that reads a directory of CSV files typically uses three of these forms within a few lines: range over a slice of file paths, range over a slice of parsed columns with the index when a column has to be rewritten in place, and range over a map of per-column totals when the summary is emitted - with a sort first if the output has to be stable across runs. Being able to say which of the four operands you are looking at, and therefore what the two variables mean, is the whole skill here. ### What range does not do here The operand is evaluated once, before the first iteration, and the second value is always a copy rather than an alias into the collection. Those two properties are where the real surprises live, and they are worth studying separately from the yield shapes above.