proposal: spec: Permit range over type sets of rangeable types

[duckbrain]

Go Programming Experience

Intermediate

Other Languages Experience

No response

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

No, however there is some overlap in use-cases with #44253

Does this affect error handling?

No

Is this about generics?

Yes, this is lifting a restriction for type sets that contain all rangeable values.

Proposal

Permit using the range operation over a parameterized type set where all types can use the range operation.

For example:

package main

import (
	"cmp"
	"fmt"
)

type List[T cmp.Ordered] interface {
	~[1]T | ~[2]T | ~[3]T | ~[4]T | ~[5]T
}

func CompareLists[T cmp.Ordered, L List[T]](a, b L) int {
	for i := range a {
		if d := cmp.Compare(a[i], b[i]); d != 0 {
			return d
		}
	}
	return 0
}

func main() {
	var a = [...]int{1, 2, 3}
	var b = [...]int{1, 3, 4}

	fmt.Println(CompareLists[int](a, b))
}

Today this code fails to compile with the following message:

./prog.go:13:17: cannot range over a (variable of type L constrained by List[T]): no core type

Per the language specification, range expressions must have specific core types, and type sets of arrays don't have a core type since every size of array is a different underlying type.

Interestingly, both len and the index expression are permitted, so the example code can be rewritten to work using a traditional for loop. This was surprising and it took me reading the language specification to realize that this was another possibility.

func CompareLists[T cmp.Ordered, L List[T]](a, b L) int {
	for i := 0; i < len(a); i++ {
		if d := cmp.Compare(a[i], b[i]); d != 0 {
			return d
		}
	}
	return 0
}

Language Spec Changes

No response

Informal Change

You can now use a range operation on generic types of mixed arrays and slices.

Is this change backward compatible?

Yes

Orthogonality: How does this change interact or overlap with existing features?

No response

Would this change make Go easier or harder to learn, and why?

Yes, currently most operations are permitted on parameterized types that are type sets of types that allow that operation. eg: the arithmetic operations, index expressions, and the built-in len function. This removes what appears to be an exception to that rule.

Cost Description

The specification becomes more complicated since the language can no longer lean on the definition of "core type" to describe which parameterized types may use a range operation.

Changes to Go ToolChain

No response

Performance Costs

No response

Prototype

No response

[gabyhelp]

Related Issues

• proposal: spec: `for int, *E := range *[]E` #69337 (closed)
• proposal: Go 2: spec: for range with defined types #47707 (closed)
• proposal: Go 2: range-over-function + range over types implementing iterator interface #65742 (closed)
• generics: incorrect error message with range clause over type sets with multiple underlying types #50738 (closed)
• Cannot range over named type literal when underlying type is a slice or array #24957 (closed)
• proposal: spec: generic type constraint for iterables #69364 (closed)
• proposal: spec: remove notion of core types #70128

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

[seankhliao]

I believe this is part of #70128