Blog / Go Language Spec

Precedence of type inference

January 10, 2024

Type inference

…

Type inference gives precedence to type information obtained from typed operands before considering untyped constants. Therefore, inference proceeds in two phases:

  1. 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.

  1. For each bound type parameter Pk for which no type argument has been inferred yet and for which one or more pairs (cj, Pk) with that same type parameter were collected, determine the constant kind of the constants cj in all those pairs the same way as for constant expressions. The type argument for Pk is 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

Share this

Direct to your inbox, daily. I respect your privacy .

Unsure? Browse the archive .

Related Content

Type unification

A couple of days ago we saw the spec reference the concept of “type unification”. Today we start through that explanation…. Type unification Type inference solves type equations through type unification. Type unification recursively compares the LHS and RHS types of an equation, where either or both types may be or contain bound type parameters, and looks for type arguments for those type parameters such that the LHS and RHS match (become identical or assignment-compatible, depending on context).

Exact & loose type unification

Type unification … Unification uses a combination of exact and loose unification depending on whether two types have to be identical, assignment-compatible, or only structurally equal. The respective type unification rules are spelled out in detail in the Appendix. The precise definitions of “exact” and “loose” unification are buried in the appendix, and depend on the specific types involved. In general, I think it’s not terribly inaccurate to say that exact unification applies when the two types are identical, for composite types with identical structure (i.

Successful type inference

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.