spec: are local types in different instantiations of a generic function identical?

[adonovan]

Are local types within generic functions distinct for each instantiation, even when they don't reference the type parameters? The current implementation says yes, but I wonder whether this is required.

See https://go.dev/play/p/3taZi53yieT for example. Each instantiation of f[T] with a different type creates a distinct local type:

var m = make(map[reflect.Type]bool)

func f[T any]() {
	type local struct{} // does not reference T
	m[reflect.TypeOf(local{})] = true
	fmt.Println(len(m))
}

f[string]() // prints 1
f[int]()    // prints 2

I think the spec should take a position one way or the other since the effect is so readily observable (unlike function equality, which we can prevent users from asking questions about). The simplest solution would be to require that the local types are distinct for each instantiation, so that "we don't have to define what it means for a local type to depend on a type parameter", as @ianlancetaylor says, noting also that "making the types distinct leads to implementation complexity if we can otherwise treat F[int] and F[MyInt] as being the same".

@ianlancetaylor @griesemer

[griesemer]

I think the argument here is that each distinct instantiation of a generic function produces a distinct non-generic function. Each of those functions has its own distinct local types, very much like any other non-generic function.

[mdempsky]

I agree that each distinct instantiation should produce a distinct defined type, regardless of which type parameters the underlying type references.

Users can always manually hoist the local defined type to package scope and explicitly add type parameters if they want finer-grained control over which type parameters affect its identity.

[timothy-king]

https://go.dev/play/p/ARWTgThVoLC shows that the current implementation can have an exponential number of distinct local types. None of these require type parameters. This is a silly example, but it does worry me a bit. Could requiring this behavior in the spec cause future problems?

[mdempsky]

@timothy-king I'm personally not concerned. You could construct an exponential number of type instantiations without local types: https://go.dev/play/p/2JZSLoIS9if?v=goprev

The type checker includes logic to make sure that instantiations are always finite.

Beyond that, I think it's up to users to make sure that finite number fits within their available build resources. E.g., we don't place any limitations on the number of unique type or function declarations a user can explicitly write in a source file.

[gopherbot]

Change https://go.dev/cl/467995 mentions this issue: go/ssa: substitute type parameters in local types

[zigo101]

There is a situation preferring identical instantiation: a non-generic function is changed to a generic one for some reason, but the author doesn't realize the result.

[adonovan]

There is a situation preferring identical instantiation: a non-generic function is changed to a generic one for some reason, but the author doesn't realize the result.

Yes, either choice is possibly surprising to someone. Treating type identity specially for nfreetypevars(T)=0 is a bit like treating new(T) specially where sizeof(T)=0.

[griesemer]

This has effectively been decided and implemented as discussed in the beginning. Leaving #65152 open for documentation and closing this one.