Type parameter declarations

August 1, 2023

Type parameter declarations

A type parameter list declares the type parameters of a generic function or type declaration. The type parameter list looks like an ordinary function parameter list except that the type parameter names must all be present and the list is enclosed in square brackets rather than parentheses.

TypeParameters  = "[" TypeParamList [ "," ] "]" .
TypeParamList   = TypeParamDecl { "," TypeParamDecl } .
TypeParamDecl   = IdentifierList TypeConstraint .

All non-blank names in the list must be unique. Each name declares a type parameter, which is a new and different named type that acts as a place holder for an (as of yet) unknown type in the declaration. The type parameter is replaced with a type argument upon instantiation of the generic function or type.

[P any]
[S interface{ ~[]byte|string }]
[S ~[]E, E any]
[P Constraint[int]]
[_ any]

I don’t think anything here is very surprising. Perhaps most notable is that, in contrast to function parameter lists, you cannot omit the names in a parameter list.

type x func(any, any) // Valid: No names in parameter list

type y List1[T1 any, T2 any] // Valid: Named parameters

type z List2[any, any] // Invalid

type q List3[_ any, _ any] // Valid: You can still use blanks for names, though

Quotes from The Go Programming Language Specification Version of December 15, 2022

Share this

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

Unsure? Browse the archive .

Related Content

Definitions of generic types

Type definitions … If the type definition specifies type parameters, the type name denotes a generic type. Generic types must be instantiated when they are used. type List[T any] struct { next *List[T] value T } We haven’t covered instantiation yet, but we will. For now, let’s just summarize: Instantiation is process by which a generic type’s type parameters are substituted with the actual type arguments to be used.

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.

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