cmd/compile,wiki: clarify whether or not the panics created in loop bodies should propagate to function iterators

[zigo101]

By the current doc, the loop body is viewed as being directly nested both in the innermost nesting function of the loop and in the yield function which is called in the iterator function.

In my opinion, the loop body should be only viewed as directly nested both in the innermost nesting function of the loop.
In other words, when a function is used as an iterator, the yield calls should viewed as being removed from the iterator function.
The effect of the doc change is that panics created in loop body are not catch-able in the iterator function.

(Another explanation: the panics created in loop bodies don't propagate to iterator functions.)

For example, the following two programs should have the same behavior, but they don't in 1.24.0 implementation. This is weird to users. By adopting the above explanations, then their behavior will become the same (the two recover calls should be both no-op).

package main

import "fmt"

func main() {
	defer foo()
}

func foo() {
	for range iter {}
	panic(123)
}

func iter(yield func(int) bool) {
	defer func() {
		fmt.Println(recover())
	}()
	yield(0)
}

package main

import "fmt"

func main() {
	defer foo()
}

func foo() {
	for range iter {
		panic(123)
	}
}

func iter(yield func(int) bool) {
	defer func() {
		fmt.Println(recover())
	}()
	yield(0)
}

[gabyhelp]

Related Issues

• runtime: recover calls in loop body of ranging over iterators doesn't take effect #71685
• runtime: recover added in range-over-func loop body doesn't stop panic propagation / segfaults printing error #71675
• runtime: confusing panic on parallel calls to yield function #68897

Related Code Changes

• spec: document for range loop over functions

Related Documentation

• Go Wiki: Rangefunc Experiment > What happens if the loop body panics? Or if the iterator function panics?
• Go Wiki: Rangefunc Experiment > What if the iterator function ignores yield returning false?
• Go Wiki: Rangefunc Experiment > What happens if the loop body defers a call? Or if the iterator function defers a call?

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[zigo101]

[edit]: sorry, pls ignored this comment. It looks I over-thought about it. It already works as such now. So the problem is much simpler than I thought.

If the above explanations are adopted, the following program should exit without unrecovered pancis (it crashes now). the two panics in the following program should be both caught? Now, only one is caught.

package main

import "fmt"

func main() {
	foo()
}

func foo() {
	defer func() {
		fmt.Println("##", recover());
	}()
	for range iter {
		panic(123)
	}
}

func iter(yield func() bool) {
	defer func() {
		fmt.Println(">>", recover());
	}()
	defer panic(789)
	yield()
}

A bit related to #34530.

In other words, if the above explanations are adopted, there might be multiple coexisting "newest" unrecovered panics in a goroutine.

[seankhliao]

cc @rsc

[mknyszek]

CC @dr2chase