New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: clarify "named" vs. "defined" types #23474

Closed
neild opened this Issue Jan 18, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@neild
Copy link
Contributor

neild commented Jan 18, 2018

The spec defines a "defined type":

A type definition creates a new, distinct type with the same underlying type and operations as the given type, and binds an identifier to it. The new type is called a defined type.

The predeclared types are, in contrast, described as "named types":

Named instances of the boolean, numeric, and string types are predeclared. Other named types are introduced with type declarations.

I believe that a "named type" and a "defined type" are clearly intended to be the same thing, but this isn't explicitly stated. This is the only place "named type" shows up in the spec; perhaps it should just be changed to "defined"?

Defined instances of the boolean, numeric, and string types are predeclared. Other defined types are introduced with type declarations.

@jimmyfrasche

This comment has been minimized.

Copy link
Member

jimmyfrasche commented Jan 18, 2018

@griesemer

This comment has been minimized.

Copy link
Contributor

griesemer commented Jan 18, 2018

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.

@griesemer griesemer closed this Jan 18, 2018

@griesemer

This comment has been minimized.

Copy link
Contributor

griesemer commented Jan 18, 2018

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.

@griesemer griesemer reopened this Jan 18, 2018

@griesemer griesemer self-assigned this Jan 18, 2018

@griesemer griesemer added this to the Go1.11 milestone Jan 18, 2018

@neild

This comment has been minimized.

Copy link
Contributor Author

neild commented Jan 18, 2018

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.

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jan 23, 2018

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

@gopherbot gopherbot closed this in 9b49ac0 Jan 23, 2018

@golang golang locked and limited conversation to collaborators Jan 23, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.