cc @griesemer

That's a very good question.

I even think, perhaps erroneously, that the case F[int]() != G() is arguably true but could also be false with my current reading of the spec.

I'm not sure I've read that right but the scoping rules around type declaration seem to speak in term of visibility not equality.

As far as I remember, named type equality is still the equality of the name (identifier), type definition literal, and package path. But it might have changed.

https://go.dev/ref/spec#Declarations_and_scope
https://go.dev/ref/spec#Type_identity

Just a remark, I have no answer.

In this case, all types involved are named types. So, the question is whether those named types are "other types" or not. Determining whether that is the case is the contention. ...

https://go.dev/ref/spec#Instantiations mentions, "instantiating a function produces a new non-generic function." So, every unique instantiation of F is a different function. That means a type declared within is different (in the identity sense) for each instantiation. This is true even if the type parameter isn't used in the type: https://go.dev/play/p/y8f4lMuhDUj (note the change to F). I recall there was some discussion on social media about this some months ago, but I'm struggling to find references now.

I believe this is the fallacy in your argument:

F[int]() == F[int]() and G() == G(), demonstrating that the created type is not tied to a call, but to the type definition AST node.

It is not solely the AST, i.e. the syntactic location, which determines type identity. All type parameters which dominate the type definition participate as well.

@zephyrtronium Ah, that actually makes sense, thank you. The behavior for non-used type parameters feels counterintuitive to me, but I guess it does follow from the spec and at least now I know :) I'll close this.

func F[T comparable]() any {
	return struct{ _ [0]T }{}
}

func G() any {
	return struct{ _ [0]int }{}
}

So it's the named types having the slightly surprising behavior -- if you use unnamed types, these two are now identical.

Yup, after rereading, seems that type names (identifiers) are unique and scoped, that's why named types are all different as per the spec.

And the type definition includes the list of type arguments indeed but for x, there was none anyway so it doesn't even matter here.

Reopening this (with title change) as a documentation issue. Similar questions have come up repeatedly and the spec could probably benefit from more explicit prose or related examples to be very clear.

dup of #58573

@griesemer

Reopening this (with title change) as a documentation issue.

Will this be documented as an unspecified behavior?

This is implicitly specified because "each distinct instantiation of a generic function produces a distinct non-generic function; and each of those functions has its own distinct local types, very much like any other non-generic function". Leaving this one open as a documentation issue and closing #58573.