How to loop with an index in Go

1for i, v := range sRecommended

Range with two variables is the idiomatic Go loop. The first variable is the index (an int, starting at 0), the second is the element. The names are yours — i, lang reads better than i, v — and the bounds are the compiler's problem, not yours, so an off-by-one is impossible. The one thing to internalise: the second variable is a copy. Assigning to it changes the loop variable, never the slice.

package main

import "fmt"

func main() {
	languages := []string{"go", "rust", "zig"}

	for i, lang := range languages {
		fmt.Println(i, lang)
	}

	// lang is a COPY of the element -- assigning to it changes nothing.
	for _, lang := range languages {
		lang = "changed"
		_ = lang
	}
	fmt.Println(languages)

	// To write, go back through the index.
	for i := range languages {
		languages[i] += "!"
	}
	fmt.Println(languages)
}

Prints 0 go, 1 rust, 2 zig, then [go rust zig] — the middle loop assigned to a copy and the slice never noticed — and finally [go! rust! zig!], where the write went through languages[i]. That copy also has a cost: ranging a []BigStruct copies the whole struct every iteration, so for large elements prefer for i := range s and touch s[i] directly. Range evaluates its expression once, so appending inside the loop can't make it run forever.

2Index only, value only, or neither

Range is happy with fewer variables. Write for i := range s and you get the index alone — the form to use when you intend to write into the slice. Write for _, v := range s and the blank identifier _ discards the index; Go rejects unused variables, so _ is how you say “I know, I don't want it”. Drop both and for range s simply repeats. Need human-facing numbering? There is no start= option like Python's enumerate — just print i+1.

package main

import "fmt"

func main() {
	tasks := []string{"write tests", "fix the bug", "ship it"}

	// Index only: leave the second variable off entirely.
	for i := range tasks {
		fmt.Printf("%d. %s\n", i+1, tasks[i])
	}

	// Value only: throw the index away with the blank identifier.
	for _, task := range tasks {
		fmt.Println("-", task)
	}

	// Neither: a bare range just counts the iterations.
	n := 0
	for range tasks {
		n++
	}
	fmt.Println("ran", n, "times")
}

Prints the numbered list 1. write tests … 3. ship it, then the same three tasks bulleted, then ran 3 times. Go 1.22 added a fourth spelling for “do this n times”: for i := range 3 ranges over an integer and yields 0, 1, 2, with for range 3 as the no-variable version. The hosted Go 1.26 compiler supports both forms. The snippet above ranges over tasks because its count should stay tied to the actual slice length.

3The three-clause loop: backwards and custom steps

for init; condition; post {} is the C-style loop, and it is the right answer whenever the index doesn't march 0, 1, 2 …. Counting down, stepping by two, stopping early on a computed bound, or advancing the index by a variable amount inside the body are all things range simply cannot express. For a plain forward walk, though, range is shorter and safer — reach for this form only when you need what it gives you.

package main

import "fmt"

func main() {
	primes := []int{2, 3, 5, 7, 11}

	for i := 0; i < len(primes); i++ {
		fmt.Println(i, primes[i])
	}

	// Backwards -- the usual reason to reach for this form
	var backwards []int
	for i := len(primes) - 1; i >= 0; i-- {
		backwards = append(backwards, primes[i])
	}
	fmt.Println(backwards)

	// Any step you like
	var everyOther []int
	for i := 0; i < len(primes); i += 2 {
		everyOther = append(everyOther, primes[i])
	}
	fmt.Println(everyOther)
}

The first loop prints 0 2 through 4 11; the reverse walk collects [11 7 5 3 2] and the stepped one [2 5 11]. Two details worth knowing: the condition is re-evaluated every iteration, so len(primes) is read each time round (fine — it's an O(1) field read, and it means the loop notices if the slice shrinks), and i is scoped to the loop, so it does not exist afterwards. If you need the final value, declare i outside. Going backwards over characters? Convert to []rune first — see reversing a string in Go.

4Ranging a string gives byte offsets, not character indexes

This is the one that bites. A Go string is a slice of bytes, conventionally UTF-8, and for i, r := range s decodes it: r is a whole rune (a Unicode code point), but i is the byte offset where that rune starts. So the indexes jump. Anything outside ASCII takes two to four bytes, and the offsets skip the gap.

package main

import (
	"fmt"
	"unicode/utf8"
)

func main() {
	s := "caf\u00e9 \u8a9e" // "caf" + e-acute, a space, then the CJK character

	// Ranging a string decodes UTF-8: i is a BYTE offset, r is a rune.
	for i, r := range s {
		fmt.Printf("byte %d -> %q\n", i, r)
	}

	fmt.Println(len(s), "bytes,", utf8.RuneCountInString(s), "runes")

	// Indexing a string gives one byte, not one character.
	fmt.Printf("%T %d\n", s[3], s[3])

	// Want real character indexes? Convert once, then range that.
	runes := []rune(s)
	fmt.Printf("%d runes, runes[3] = %q\n", len(runes), runes[3])
}

The offsets come out 0, 1, 2, 3, 5, 6 — there is no 4, because é occupies bytes 3 and 4, and no 7 or 8 because 語 takes three bytes. The string is 9 bytes, 6 runes. Indexing with s[3] doesn't give you a character at all: uint8 195, the first byte of the two that encode é. If you want an index that counts characters, convert once with []rune(s) and range that — runes[3] is 'é', as you'd expect. That conversion allocates, so do it once outside the loop, never inside it.

5The loop variable, closures, and the Go 1.22 change

Before Go 1.22, i and v were one variable reused for the whole loop. Every closure created inside the body captured that same variable, so by the time you called them they all saw the final value — the notorious “every goroutine printed the last item” bug. Go 1.22 changed the spec: in a module declaring go 1.22 or later, the loop variables are fresh on every iteration, and the bug is gone. The explicit fix still works everywhere and still documents intent, which is what the snippet below uses: shadow the variable with i, item := i, item, or pass it into the goroutine as an argument.

package main

import (
	"fmt"
	"sync"
)

func main() {
	items := []string{"a", "b", "c"}

	// One closure per iteration. The `i, item :=` line makes the per-iteration
	// copy explicit -- exactly what Go 1.22 started doing for you.
	var fns []func() string
	for i, item := range items {
		i, item := i, item
		fns = append(fns, func() string { return fmt.Sprintf("%d:%s", i, item) })
	}
	for _, f := range fns {
		fmt.Println(f())
	}

	// Goroutines: pass the values in as arguments and they are copies on every
	// Go version. Each result lands in a fixed slot, so nothing can reorder.
	out := make([]string, len(items))
	var wg sync.WaitGroup
	for i, item := range items {
		wg.Add(1)
		go func(i int, item string) {
			defer wg.Done()
			out[i] = fmt.Sprintf("%d=%s", i, item)
		}(i, item)
	}
	wg.Wait()
	fmt.Println(out)
}

Prints 0:a, 1:b, 2:c, then [0=a 1=b 2=c]. Being honest about the runner: the interpreter behind these embeds still follows the pre-1.22 rule, so if you delete the i, item := i, item line and hit Run, all three closures report the same, final values instead of 0:a, 1:b, 2:c — the historical bug, live. A real Go 1.22+ toolchain gives the right answer either way. That difference is exactly why the explicit copy is worth keeping in code that has to run on more than one toolchain. Note also that the goroutine results are written into fixed slots of out rather than printed directly — goroutine scheduling order is never guaranteed, and no language version fixes that.

6Which should you use?