I care less about hooking into range and more about the performance. I would really like for iterators to be zero-cost abstractions, but right now a SliceIter is waaaayyy slower than looping over a slice (with range or otherwise). The Go compiler isn’t smart enough to realize that a loop over a SliceIter can be reduced to a loop over a slice, perhaps because it can’t know for certain that the loop counter variable (e.g. the `counter` field in `type SliceIter[T any] struct { slice []T; counter int }`) is only being accessed by the loop itself (this might be where Rust’s ownership semantics would be useful in Go?).