proposal: generic should infer type from variable definition

[LeGamerDc]

hope go could support infer generic type from variable type

func main() {
	var x Person = get() // to replace var x = get[Person]()
	fmt.Println(x)
}

func get[T any]() T {
	var x T
	return x
}

[ianlancetaylor]

I suppose this would be a little bit like way that the language handles untyped constants, in that the type of the function would be inferred based on how the function call expression is used. But there would be a big difference, which is that untyped constants have a default type, but here the "default type" would be a compiler error.

I'm concerned that the rules for when the type is inferred would be unclear to the person reading the program. People already get confused about untyped constants.

In any case putting this on hold for later consideration after we have more experience with generics.

[leaxoy]

And generic parameter should can be infer lazily.
For example:

m := NewHashMap[int, int]() 
m.Put(1, 2)

can write as:

m := NewHashMap() // currently type parameter is not set.
m.Put(1, 2) // type parameter set to (int, int)

[ianlancetaylor]

@leaxoy That seems very different to me, and should be a separate issue, not this one. Thanks.

[mlevieux]

While this is on hold, I'd like to give my two cents on this one:
I don't want type inference to get too smart, and IMO nobody should wish for this. When we'll start having big projects using generics, or complex libraries with functions having a certain number of type parameters, differing in subtle ways, interacting with each other etc... it'll become more and more difficult to read generic code, up to the point where (and that is already the case in a number of languages) it'll be necessary to know a tremendous part of the codebase to know what types you're actually dealing with, their constraints and such. So I left a thumb down, not because I think this is bad in itself, I just feel like it goes against Go's philosophy.

[changkun]

For the following g and f:

func f[T any]() (x T) { return }
func g[T any](x ...T) { return }

On the call side, because the current type inference is only limited based on function arguments, we can infer g from the return type of f:

g(f[int]()) // OK

But not the vise versa:

g[int](f()) // ERROR: cannot infer T

This seems OK initially since it applies the philosophy of "there is only one way of doing something". However, whenever we trying to do something with ..., it feels so much wierd (am I the only person?):

g(f[int](), f[int](), f[int](), f[int](), f[int]()) // OK
g[int](f(), f(), f(), f(), f())                     // ERROR: cannot infer T

One must write the first style rather than the second. Was there a particular example (similar to other known limitations caused by particular examples) to prevent this during the design cycle of 1.18's generics?