Type inference gives precedence to type information obtained from typed operands before considering untyped constants. Therefore, inference proceeds in two phases:
- The type equations are solved for the bound type parameters using type unification. If unification fails, type inference fails.
Type unification comes up next in the spec, so we’ll learn exactly what that means soon.
- For each bound type parameter
kfor which no type argument has been inferred yet and for which one or more pairs
)with that same type parameter were collected, determine the constant kind of the constants
jin all those pairs the same way as for constant expressions. The type argument for
kis the default type for the determined constant kind. If a constant kind cannot be determined due to conflicting constant kinds, type inference fails.
So TL;DR; use the knowledge we already gained about how an untyped constant’s type is determined, and apply that to any untyped constants in the unsolved type equations. If there’s a conflict, type inference fails.
If not all type arguments have been found after these two phases, type inference fails.
It took a long build up, but the conclusion is pretty straight forward. If all the last several days of logic end up failing… type inference fails.
Tomorrow we’ll conclude this section of the spec with the happy path… when type inference doesn’t fail!
Quotes from The Go Programming Language Specification Version of August 2, 2023