Some Facts About Go Iterators

• A simple introduction of Go iterators
• Don't call a yield callback again if a call to the callback has ever returned false
• Don't call the yield callback of an iterator function if the iterator function has returned
• Calling a yield callback function concurrently needs careful synchronizations
• The top function calls in the call stack of a goroutine will be executed concurrently when ranging over iterator functions
• Calling an iterator function explicitly might be equivalent to ranging over the iterator function or not
• The iterator design has a flaw
• The implementation of iterators still has some bugs
• The importance of iterators has not been proved yet

A simple introduction of Go iterators

func(func() bool)
func(func(V) bool)
func(func(K, V) bool)

// K and V both denote types.

package main

import "fmt"

func main() {
	for v := range abc {
		fmt.Print(v)
	}
}

func abc(yield func(string) bool) {
	if yield("a") {
		if yield("b") {
			yield("c")
		}
	}
}

• Three arguments "a", "b" and "c" are in turn passed to the string paramter and are used as the values of (the instances of) the loop variable v.
• The loop body can be basically viewed as the function body of the yield function. Just note that, if the execution of a loop step during ranging over an iterator function terminates the whole loop (such as break the loop), then the corresponding yield call returns false (to the iterator function); otherwise the corresponding yield call returns true.

func abc(yield func(string) bool) {
	_ = yield("a") && yield("b") && yield("c")
}

Don't call a yield callback again if a call to the callback has ever returned false

package main

import "fmt"

func main() {
	for v := range ab {
		fmt.Println(v)
		break // remove this line to avoid crashing.
	}
}

func ab(yield func(string) bool) {
	var done = yield("a")
	fmt.Println(done) // false
	
	yield("b") // runtime error: range function
	           // continued iteration after function
	           // for loop body returned false.
}

Don't call the yield callback of an iterator function if the iterator function has returned

package main

import "fmt"

var f func(string) bool

func main() {
	for v := range abc {
		fmt.Print(v)
	}
	f("d") // runtime error: range function
	       // continued iteration after
	       // whole loop exit
}

func abc(yield func(string) bool) {
	_ = yield("a") && yield("b") && yield("c")
	f = yield
}

Calling a yield callback function concurrently needs careful synchronizations

package main

import "fmt"
import "sync"

var c = make(chan int)

func main() {
	// runtime error: range function continued iteration after loop body panic
	for v := range oneHundred {
		<-c
		fmt.Println(v)
	}
}

func oneHundred(yield func(int) bool) {
	var wg sync.WaitGroup
	for v := range 100 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			yield(v)
		}()
	}
	close(c)
	wg.Wait()
}

func abc(yield func(int) bool) {
	var wg sync.WaitGroup
	var mu sync.Mutex // use a mutex to sync
	for v := range 100 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			mu.Lock()         // prevent yield being
			defer mu.Unlock() // called parallelly.
			yield(v)
		}()
	}
	close(c)
	wg.Wait()
}

The top function calls in the call stack of a goroutine will be executed concurrently when ranging over iterator functions

package main

import "fmt"

func main() {
	for v := range abc {
		fmt.Print(v)
	}
}

func abc(yield func(string) bool) {
	for i, v := range "abc" {
		fmt.Print(i)
		if (!yield(string(v))) {
			break
		}
	}
}

package main

func wrap(it func(yield func(int) bool)) func(yield func(int) bool) {
	return func(yield func(int) bool) {
		for v := range it {
			yield(v+1)
		}
	}
}

func main() {
	iterator := func(yield func(int) bool) {
		_ = yield(0) && yield(1) && yield (2)
	}
	for range 1 << 22 { // 23 crashes the program
		iterator = wrap(iterator)
	}
	for v := range iterator {
		println(v)
	}
}

Calling an iterator function explicitly might be equivalent to ranging over the iterator function or not

func abc(yield func(string) bool) {
	_ = yield("a") && yield("b") && yield("c")
}

	for v := range abc {
		fmt.Print(v)
	}

	abc(func(v string) bool {
		fmt.Print(v)
		return true
	})

func abcThenPanic(yield func(string) bool) {
	_ = yield("a") && yield("b") && yield("c")
	panic("bye")
}

	for v := range abcThenPanic {
		defer func() {
			recover()
		}()
		fmt.Print(v)
	}

	abcThenPanic(func(v string) bool {
		defer func() {
			recover()
		}()
		fmt.Print(v)
		return true
	})

The iterator design has a flaw

package main

func main() {
	defer func() {
		var v = recover()
		println(v == 123)
	}()
	for range iter {
		panic(123)
	}
}

func iter(yield func() bool) {
	defer func() {
		recover()
	}()
	yield()
}

package main

func main() {
	defer func() {
		var v = recover()
		println(v == 123)
	}()
	for range iter {}
	panic(123)
}

func iter(yield func() bool) {
	defer func() {
		recover()
	}()
	yield()
}

1. the panic created in the loop body of ranging over an iterator function will propagate to the iterator function.
2. the iterator function should not recover the panic created in the loop body. If the iterator function recovers the panic propagated from the loop body, then the runtime will create a new runtime panic implicitly.

The implementation of iterators still has some bugs

package main

import "fmt"

func main() {
	defer foo()
	panic(123)
}

func foo() {
	for range iter {
		fmt.Println(recover())
	}
}

func iter(yield func() bool) {
	yield()
}

package main

import "fmt"

func main() {
	defer foo()
	panic(123)
}

func foo() {
	for range 1 {
		fmt.Println(recover())
	}
}

The importance of iterators has not been proved yet