Why a Go Language Founder Apologized for a Decade-Old Spec Typo and How It’s Finally Fixed

Spec contradiction

In the Go language specification the Types section defines "Predeclared types, defined types, and type parameters are called named types." The Boolean types subsection then states "the predeclared boolean type bool; it is a defined type." This wording makes a type appear both predeclared and defined, which is logically inconsistent.

Community debate (Issue #78208)

Developers opened https://github.com/golang/go/issues/78208 and argued that bool cannot be a defined type because only types declared with the type keyword can have methods. For example, type MyInt int can have methods, whereas bool cannot.

Another side countered that the spec never says the three categories are mutually exclusive; "predeclared" merely means the type is built‑in, and it can still be a defined type whose definition is invisible to users.

Historical evolution of the terminology

Go 1.0 : the language distinguished only named and anonymous types. Predeclared types such as int and bool had unique type identities and were treated as named types.

Go 1.9 introduced type aliases, e.g. type NewString = string. An alias shares the same identity as its underlying type, breaking the earlier assumption that "named" equals "unique identity". To preserve identity, the team renamed the former "named types" to Defined Types , inadvertently classifying predeclared types as defined.

Go 1.18 added generics. Type parameters ( T, P) require distinct identities, so the team revived the term Named Type to denote any type with a unique identity, separating it from the newer "Defined Type" concept.

Spec correction

Robert Griesemer posted a lengthy response, admitted the wording error, and submitted a change list that updates the spec to state that predeclared types are named , not defined . The CL also clarifies that any is simply an alias for interface{}. The change list can be viewed at https://go-review.googlesource.com/c/go/+/757120.

Practical impact on code

Understanding the distinction is essential for generic constraints. The constraint ~string matches both the built‑in string and a defined type such as type MyString string, while a plain string constraint rejects values of MyString.

Method sets are also affected: methods can only be attached to types introduced with the type keyword. Consequently, bool cannot have methods, preserving a safety boundary that prevents modification of built‑in types.