proposal: reflect: add Type.CanSeq0 and Value.Seq0

[rothelius]

Proposal Details

It is possible to range over expressions of type func(func()bool) (and similar), but there's no simple way to test whether a given type allows range-variable-less ranging, or to perform a range over a reflect.Value of such a type.

Methods reflect.Type.CanSeq0 and reflect.Value.Seq0, implemented in the manner of corresponding Seq and Seq2 methods, would solve this.

[mvdan]

The relevant part of the spec wasn't obvious to me, so I'll copy paste it here:

Range expression                                       1st value                2nd value
[...]
function, 0 values  f  func(func() bool)
function, 1 value   f  func(func(V) bool)              value    v  V
function, 2 values  f  func(func(K, V) bool)           key      k  K            v          V

[gabyhelp]

Related Issues

• reflect: add Type.CanSeq/CanSeq2 and Value.Seq/Seq2 methods #66056 (closed)
• reflect: Add Type.Fields() iter.Seq[StructField] and Type.Methods() iter.Seq[Method] #66631 (closed)
• spec: add range over int, range over func #61405 (closed)
• proposal: spec: range over nil function values should not panic #65629 (closed)
• reflect: add a range like interface for Value #11104 (closed)
• proposal: Go 2: function values as iterators #43557 (closed)
• proposal: Go 2: spec: for range with defined types #47707 (closed)
• reflect: Type.CanSeq[2]: false positive for Seq-like function types with named bool type #77542
• proposal: Go 2: range-over-function + range over types implementing iterator interface #65742 (closed)

Related Discussions

• user-defined iteration using range over func values

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

[apparentlymart]

To keep this aligned with the conventions for the other two supported arities, perhaps this proposal should also extend package iter to match:

package iter

type Seq0 func(yield func() bool)

The method in reflect could then be defined consistently with its other two existing variants, with each using the matching named type:

package reflect

func (Value) Seq0() iter.Seq0

Presumably this particular variant would only be valid for function-typed values of the right signature, because no other type can currently be used with range to produce zero results per iteration.

Edit: As noted in the comment below, the range syntax with no results requires something that produces at least zero results per iteration rather than exactly zero results, and so this should actually work for anything that could be used after range, including everything that the Value.Seq and Value.Seq2 methods already support, with the results just discarded.

[rothelius]

Presumably this particular variant would only be valid for function-typed values of the right signature, because no other type can currently be used with range to produce zero results per iteration.

Well, this is all valid:

	for range 5 {
	}
	for range []bool{} {
	}
	for range [3]int{} {
	}
	for range map[int]int{} {
	}
	for range func(func(int, int) bool) {} {
	}

And Type.CanSeq reports true for any type that Type.CanSeq2 reports true for (except for iter.Seq2s, for some reason), so Type.CanSeq0 should probably report true for any type that Type.CanSeq does.

[earthboundkid]

As the author of #66056, I'm kind of embarrassed we didn't do this already. 😅

I agree with @apparentlymart that it should be pair with an iter.Seq0 type that exists just for documentation. I feel like it existed in one of the rangefunc demo versions. Does anyone recall why it didn't make it into the final implementation API?

[apparentlymart]

Now that you remind me about #66056, I notice that the idea in this proposal was raised there in #66056 (comment), but it wasn't mentioned again in any subsequent comment so it doesn't seem like it was explicitly rejected, just overlooked? 🤷‍♂️

[earthboundkid]

Yeah Merovius and I both mentioned Seq0 but we all forgot to follow up on it.