I'm not sure I follow.

In my mind

• unifying P = int is correct because that's what x is
• g[string](x) should be an error because string ≠ int

That P is not currently used by T does not seem relevant. Say you allow g[string] but then in a later version T is updated to

type T[P any] interface {
	m() P
}

now g[string] is an error and the correct inference would be int but the only thing that changed was an implementation detail

Consider this case:

type T1[P any] interface {
	m()
}

type T2[P any] interface {
	m()
}

func g[P any](T1[P]) {}

func _() {
	var x T2[int]
	g(x)         // here we infer P == int, but in fact any type of P would be ok
	g[string](x) // here we set P == string
}

Now we get an error for g(x) but g[string](x) is ok. That seems inconsistent. We should not be able to infer a type for P in the first case.

I see what you are saying. The interfaces-as-constraints are identical to each other and interface { m() } so P does not matter for the constraint.

However, it seems like the parameterization of the interface-as-type should still be part of its identity.

@jimmyfrasche that's why it's inference which would fail.

But not instantiation.

I expect it to behave like this, since the interface(s) aren't used as constraints and are just ordinary types:

type T[P any] struct{}

func g[P any](T[P]) {}

func _() {
	var x T[int]
	g(x)         // here we infer P == int
	g[string](x) // here we fail to set P == string as P = int
}

https://go.dev/play/p/0Wj38UCOijw

@jimmyfrasche But the rules for interface assignment are quite different from non-interface assignment. But here is a counter-example:

type T[P any] interface{ m() }

func g[P any](func(T[P])) {}

func _() {
	var f func(T[int])
	g(f)
	g[int](f)
	g[string](f) // ERROR cannot use f (variable of type func(T[int])) as func(T[string]) value in argument to g[string]
}

Because the interface is a component type, now it must match exactly.

Ah, I was so fixated on the type inference I wasn't thinking about assignability. g[string](x) makes total sense.

I still do not see why that implies that int should not be inferred, though. Even if other choices are valid, it seems reasonable to go with what's provided.

I believe type inference should only infer a type if it is the only one possible, if a valid type argument exists in the first place (ignoring the fact that in many cases any is also a valid type argument).

This may mean that in some cases (like this one) we cannot infer a type argument. That's ok.

I agree that type inference should not invent a type but I disagree that it should discard the provided type. I don't think this would matter much given how niche the edge case is, though.

Would g(T[int](x)) also fail? This case is identical but it feels more wrong written like this.

g(T[int](x)) is the same as g(x) if x is of type T[int]. So g(T[string](nil)) currently works but would fail if we consider this issue a bug. Consider g[int](T[string](nil)) which works either way.

In other words, currently we have an exception for defined generic interface types: if a defined generic interface type T which is instantiated with a concrete type X (assuming there's one type parameter) is then matched against the same interface type "instantiated" with a type parameter, we infer the type X for the type parameter, even if the type parameter is never used by the methods: T[X] unified against T[P] leads to the inference of X for P.

If we consider this issue a bug, then a) we don't need an exception anymore, but b) in this example we wouldn't be able to infer X anymore.

I think this is a pretty esoteric case and doesn't really justify the exception.

See also #8082 which applies when the interface types are components of other types.

cc: @mdempsky @findleyr for input, especially considering also #8082.

@jimmyfrasche the way I see it, inference is the reverse of instantiation.
Similarly to solving an equation, we start from the result and try to find the unknown (the type argument).

We know that a type parameter can only have one instantiation at a time. So the solution is unique.

Each constructed type is unique and new: T[int] and T[string] are different but compatible in assignment to each other.

That last part tripped me a little bit though, I admit 😅. This is the type identity/equality of interfaces that @griesemer linked and which impacts composite type definitions.

But non generic go code still considers that two type definitions are different although possibly compatible.

We know that a type parameter can only have one instantiation at a time. So the solution is unique.

A type parameter can have only one instantiation at a time but that doesn't mean the solution to inference is unique: in the original example in this issue type inference infers int but in fact any type would solve the equation. So the solution is not unique at all.

Exactly, that's why inference fails.

It's a case similar to f(x) = c where c is constant.

Given c, we are still trying to find the one value of x that we passed to f.

That's what was meant by unique, I don't disagree at all.

I think the framing provided by @griesemer and @atdiar is useful: if the solution is not unique, inference should fail. Otherwise, we run the risk of inferring a different type in the future (and that's exactly why we need the special case currently).

I'll note that there are other cases where there is one unique solution, and inference fails because of the current implementation:

type S[P any] interface{}

func F[P any](S[P], P) {}

func _() {
	var s S[int]
	F(s, "")
}

@findleyr 's example is very convincing. Fix forthcoming.

Clarification: It is better to not be able to infer a (possible) type argument when we could than to infer an incorrect type argument (which is the case in this example). The former is a shortcoming of the inference mechanism, while the latter is a bug.

Change https://go.dev/cl/498315 mentions this issue: go/types, types2: don't infer type argument for unused parameter in interfaces

Here's an example where inference will continue to succeed, but infer a different type:

type S[P any] interface{}

func F[P any](S[P], P) P { var x P; return x }

func main() {
	var s S[float64]
	y := F(s, 1)
	_ = y
}

IMO this is an example of the current algorithm inferring the "wrong" type. The type of y is inferred to be float64, but should be int (and will be after this issue is fixed).

@findleyr can inference work with untyped const values here?
After the change, I might try to assign y to a float64 variable for instance (somewhere else in the code after the call to F)

Perhaps it should fail here too because there are several solutions, 1 could be int or float32 or float64 etc...?

https://go.dev/play/p/rHxWDwvTNek

Edit: ha I think I see what you meant:

https://go.dev/play/p/SHeQwzAeBRy

That's indeed something that should be dealt with by the fix.

@atdiar Your 2nd example will work with the fix.

Change https://go.dev/cl/498895 mentions this issue: go/types, types2: use exact unification for component types

This should be too late, and I am sorry if this was already discussed, but wouldn't it be possible to forbide unused type parameters by the Go compiler? In other words, couldn't Go compiler forbid the following code?

type T[P any] interface {
	m()
}

I realized that unused type parameters tend to cause counterintuitive implicit conversions (https://go.dev/play/p/VLb031yF1z6, inspired by #61903). Also, unused parameters are unused then these should be useless. (If we really want to have a unused type parameter, we can add a member like [0]T somewhere).

What do you think?

@hajimehoshi then someone will want this (probably with some good reason), asking: "Where are my phantom types?"

:o)

(phantom type is the usual name of this feature)

Edit: now that I think of it, since you only want to disable it for interface types, I think it will depend on how the question of interface identity is solved.

OK so my question is when phantom types are useful.

EDIT: https://doc.rust-lang.org/rust-by-example/generics/phantom.html

I see, so if they need to use phantom types, I was wondering if it would be possible to 'convince' the Go compiler by adding a member like [0]T somewhere.

@hajimehoshi in general to express units.

type Distance[Unit any] float64
type Miles struct{}
type Meters struct{} 

type DistanceMiles = Distance[Miles] 
type DistanceMeters = Distance[Meters] 

I'd think.

But your question is more interesting and I responded a bit too fast, since you are especially targeting the case of interface types.

I'm curious as well to see what people think.

Edit: now that I think of it, since you only want to disable it for interface types, I think it will depend on how the question of interface identity is solved.

Good point. Probably what I want to solve is counterintuitve assignment to an interface type. For non-interface types, such a counterintuitive assignment should not happen as far as I understand. So, forbidding an unused parameter for an interface type might be enough, beside consistency.