cc @griesemer

They (named and defined typed) are not (anymore, since we have type aliases) the same thing: A named type is simply a type with a name (which might be an alias name). A defined type is also a type with a name, but it happens to be given a name via a type definition.

A predeclared type might or might not be a defined type, it doesn't really matter much (at least I haven't heard a compelling reason why it would matter). We could call them defined types, but then we have a question about 'uint8' vs 'byte': which of the two is the "original" defined type, and which one is the alias? As is, both of them are just named types, their names are handles for some predeclared (underlying) type that is otherwise unnamed. For instance, think of byte as simply a name for the built-in, unnamed instance of the byte type.

Thus I prefer to leave it explicitly as is.

I'm going to reopen this. @neild convinced me that there are good reasons to explicitly state that built-in types are defined types (if they were not, we would be able to assign a value of int to a defined variable of type myint where type myint int). Also, we should probably clean up the use of type name vs named type in the spec.

One point mentioned in offline discussion: I'm not certain that it makes sense to say that a type alias is a named type. If we write type T = struct{}; var x T, all of the following statements are (I think) clearly true:

• The type of x is T.
• The type of x is struct{}.
• struct{} is not a named type.
• The type of x is not a named type.

If T is a named type, then the type of x simultaneously is and is not a named type, which is just confusing.

I think the simplest way to resolve this confusion is to not use the words "named type" in the specification. The terms "type name" and "defined type" are unambiguous.

Change https://golang.org/cl/89115 mentions this issue: spec: consistently use "defined type" and "type name" (cleanup)