proposal: spec: apply constraint type inference to generic types

[itsmontoya]

Author background

• Experienced Go Engineer, over 8 years experience
• Rust, C, Zig

Related proposals

• I am not sure if this idea has been proposed before
• This idea does not effect error handling
• This proposal is about generics

Proposal

• The proposed change is to allow for better type inference when working with generic referencing interfaces
• This proposal helps anyone who uses generics in a factory or generator pattern. Additionally, anyone writing data structures
• The purpose of this proposal is to allow for interface types referencing generics type MyInterface[T] interface { *T } to be inferred better
• The ability to infer types for interfaces targeting a pointer value of a generic type
• Allow for pointer types of structs to be inferred more easily by Golang generics
• The change is backward compatible
• This change does not affect existing features
• This change is not a performance improvement

Costs

• This would not affect the learning scale of Go as it's a deeper subject. For more experienced Engineers, it should make generics more simple to work with
• More work on the compiler to perform stronger inferring
• gopls would be affected
• Negligible, but a slight performance cost
• No runtime cost
• A use-case for this feature is available here
• No prototype is available for the implementation of this feature

Example - Current Requirement

package main

import (
	"strconv"
)

func main() {
	c := New[testType]()
	c.Txn(func(txn Txn[testType, *testType]) {
		txn.New(testType{val: "1"})
		txn.Update("0", func(tt testType) (out testType) {
			return
		})
	})
}

func New[T any, U Value[T]]() *Controller[T, U] {
	var c Controller[T, U]
	c.m = make(map[string]T)
	return &c
}

type Controller[T any, U Value[T]] struct {
	idx int
	m   map[string]T
}

func (c *Controller[T, U]) Txn(fn func(Txn[T, U])) {
	var txn Txn[T, U]
	txn.c = c
	fn(txn)
}

type Txn[T any, U Value[T]] struct {
	c *Controller[T, U]
}

func (txn *Txn[T, U]) New(t T) {
	u := U(&t)
	u.SetID(strconv.Itoa(txn.c.idx))
	txn.c.idx++
}

func (txn *Txn[T, U]) Update(key string, fn func(T) T) {
	v, ok := txn.c.m[key]
	if !ok {
		return
	}

	txn.c.m[key] = fn(v)
}

type testType struct {
	id  string
	val string
}

func (t *testType) SetID(id string) {
	t.id = id
}

type Value[T any] interface {
	*T
	SetID(string)
}

Example - Proposal

package main

import (
	"strconv"
)

func main() {
	c := New[testType]()
	c.Txn(func(txn Txn[testType]) {
		txn.New(testType{val: "1"})
		txn.Update("0", func(tt testType) (out testType) {
			return
		})
	})
}

func New[T any, U Value[T]]() *Controller[T, U] {
	var c Controller[T, U]
	c.m = make(map[string]T)
	return &c
}

type Controller[T any, U Value[T]] struct {
	idx int
	m   map[string]T
}

func (c *Controller[T, U]) Txn(fn func(Txn[T, U])) {
	var txn Txn[T, U]
	txn.c = c
	fn(txn)
}

type Txn[T any, U Value[T]] struct {
	c *Controller[T, U]
}

func (txn *Txn[T, U]) New(t T) {
	u := U(&t)
	u.SetID(strconv.Itoa(txn.c.idx))
	txn.c.idx++
}

func (txn *Txn[T, U]) Update(key string, fn func(T) T) {
	v, ok := txn.c.m[key]
	if !ok {
		return
	}

	txn.c.m[key] = fn(v)
}

type testType struct {
	id  string
	val string
}

func (t *testType) SetID(id string) {
	t.id = id
}

type Value[T any] interface {
	*T
	SetID(string)
}

[DeedleFake]

There's an awful lot of what looks, to me at least, like extraneous information in those code examples that are kind of obscuring the actual change. The diff between the two is just

@@ -6,7 +6,7 @@
 
 func main() {
 	c := New[testType]()
-	c.Txn(func(txn Txn[testType, *testType]) {
+	c.Txn(func(txn Txn[testType]) {
 		txn.New(testType{val: "1"})
 		txn.Update("0", func(tt testType) (out testType) {
 			return

[deltamualpha]

And as far as I can tell that's only possible in the specific case [T any, U Value[T]] -- "The ability to infer types for interfaces targeting a pointer value of a generic type"?

[tdakkota]

It seems this issue is about redundant parameter type declaration in closures.
See #21498.

[DeedleFake]

It seems this issue is about redundant parameter type declaration in closures.
See #21498.

I'm not sure about that. I think it's actually related to a specific case of structural constraints.

[ianlancetaylor]

Can you describe the new type inference that you are looking for using the kind of language as issue #58650?

Can you provide a minimal example?

Thanks.

[itsmontoya]

There's an awful lot of what looks, to me at least, like extraneous information in those code examples that are kind of obscuring the actual change. The diff between the two is just

@@ -6,7 +6,7 @@
 
 func main() {
 	c := New[testType]()
-	c.Txn(func(txn Txn[testType, *testType]) {
+	c.Txn(func(txn Txn[testType]) {
 		txn.New(testType{val: "1"})
 		txn.Update("0", func(tt testType) (out testType) {
 			return

You're 100% correct. Sorry about that! Thank you for clarifying the changes

[itsmontoya]

Can you describe the new type inference that you are looking for using the kind of language as issue #58650?

Can you provide a minimal example?

Thanks.

It looks as though my explained issue would be solved by #58650 (Constraint type inference 2)

[ianlancetaylor]

The "Constraint type inference 2" example already works, though, so there is some essential difference in this proposal.

[Merovius]

I think the essential difference - based on the diff - is that this proposal is about applying constraint type inference to generic types, not just generic function calls. That is, the goal is to make this work:

package main

func main() {
	var x X[*S]
	_ = x
}

type C[T any] interface {
	*T
	M()
}

type X[PT C[T], T any] struct {
	v T
}

func (x *X[PT, T]) N() {
	PT(&x.v).M()
}

type S struct{}

func (*S) M() {}

This proposal specifically asks about a situation where the type appears as the argument type in a function-literal passed to a function call. But I think the main hurdle is still, that we don't even try to infer type-arguments for generic types.

[itsmontoya]

@Merovius you make some fantastic points and you are 💯 correct. I appreciate you noticing the subtle differences that I missed.

[ianlancetaylor]

CC @griesemer

[griesemer]

@itsmontoya We're not doing any inference (specifically "constraint type inference") when instantiating generic types for now because of issues with type cycles that we don't fully understand: in contrast to generic functions, a generic type may occur in its own type parameter list (e.g., as constraint or part of a constraint), directly or indirectly. The resulting cycles lead to difficult problems. We probably could detect such (for now) invalid cycles, but that also requires some theory behind it; and we haven't had time to look into this.

We may do this at some point but nothing is planned in the near future. Putting on hold for now.