proposal: spec: range over nil function values should not panic

[tamayika]

Proposal Details

Environment: Go 1.22 with GOEXPERIMENT=rangefunc

Currently, we can iterate nil slice and nil map with for range and nil channel blocks forever.
But, nil iter.Seq[T] panics.
I think it's better if we can iterate nil sequence like nil slice.
Also, I can't find this is desinged or not at https://go.dev/wiki/RangefuncExperiment.

func main() {
	var (
		slice []int
		m     map[string]int
		ch    chan int
		iter  iter.Seq[int]
	)
	// ok
	for range slice {

	}
	// ok
	for range m {

	}
	// block forever
	for range ch {

	}
	// panic
	for _ = range iter {

	}
}

[earthboundkid]

Seems more logically consistent and it makes it easier to return a blank iterator in different spots. You might do var seq iter.Seq[int]; if cond { seq = something() }; for n := range seq { /**/ } like you do with channels. This saves you from needing to write a dummy iterator or put one in the iter package.

[timothy-king]

Personally I am somewhat torn on this one. nil maps and slices have consistent meanings in different operations, an empty map and an empty slice. Other operations make sense on them, len(s) == 0, or m["key"]==false. A nil function value f panics when called. The other operation is comparison to nil. This proposal is effectively saying 'nil function values [with such and such a signature] are empty sequences'. That is definitely more forgiving and has its uses. It is also relatively easy to adjust the implementation.

Ranging over a nil pointer to array value does panic if two iteration variables are present (and len(array)>=1). So there is some precedent for panicking. It would arguably be more confusing for it to be considered an empty sequence. I think the mental model being put forward is for for range f { ...} to be f(func(int)bool{ ... }). That would panic when f is nil.

I think both views are somewhat reasonable.

[AndrewHarrisSPU]

ISTM there would be expected behaviors for the most referentially transparent iter.Seq generated from a nil slice/map/channel. The behavior would be different between finite slices and maps, and arbitrarily long / infinite channels. With finite sequences, terminating the loop seems obvious, and blocking would be perplexing. I wonder if terminating when one really expects an infinite sequence is equally perplexing - the root cause of resulting problems might not be as immediate as the consequences at run time.

If iter.Seq generalizes finite and infinite sequences and complications in-between, a nil panic isn't pleasant but isn't subtle either.

[Jorropo]

As a side effect if we change this that means any manual handling of the iterator will need to manually handle both.
Currently you can write:

func Concat[V any](iterators ...iter.Seq[V]) iter.Seq[V] {
 return func(yield func(V) bool) bool {
  for _, i := range iterators {
   if !i(yield) {
    return false
   }
  }
  return true
 }
}

vs:

 func Concat[V any](iterators ...iter.Seq[V]) iter.Seq[V] {
  return func(yield func(V) bool) bool {
   for _, i := range iterators {
+   if i == nil {
+    continue
+   }
+
    if !i(yield) {
     return false
    }
   }
   return true
  }
 }

[rsc]

Iterators are functions; calling nil functions panics. If a direct call and a use in range behaved differently, then that would be a gotcha when thinking about having to convert code from one form to the other.

Nil iterators are a mistake and should not be used, same as nil pointers.

[rsc]

Some ranges do panic by the way: https://go.dev/play/p/B_tw9VJ11ZU

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group