Today we finish up the discussion on type inference. So we’ve now

Type inference

…

If the two phases are successful, type inference determined a type argument for each bound type parameter:

	Pk ➞ Ak

A type argument Ak may be a composite type, containing other bound type parameters Pk as element types (or even be just another bound type parameter). In a process of repeated simplification, the bound type parameters in each type argument are substituted with the respective type arguments for those type parameters until each type argument is free of bound type parameters.

So in the simple case, our Pk ➞ Ak algorithm results in something like: T ➞ int. But it might be a composite type, too: T ➞ []string or T ➞ struct { Name string; Age int}… or even T ➞ []P, where P is another type parameter for which we need to resolve the equations we just spent the last few days going through.

So this process can repeat…

If type arguments contain cyclic references to themselves through bound type parameters, simplification and thus type inference fails. Otherwise, type inference succeeds.

Yeah… so as we’ve seen before, Go really doesn’t like cyclical references. I like that about Go. 😊

And there we have it… It only took… (let me count…) 5 days to get through this section of the spec on type inference.

Next up: A slog through Type unification. Then on to something a bit more mundane: operators.

Quotes from The Go Programming Language Specification Version of August 2, 2023