Skip to content
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

doc: Effective Go contains a use of "named type", which is an obsoleted terminology. #32496

Closed
go101 opened this issue Jun 8, 2019 · 10 comments

Comments

@go101
Copy link

commented Jun 8, 2019

Should it be "defined type" instead?

@agnivade

This comment has been minimized.

Copy link
Member

commented Jun 9, 2019

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

Neither occurrence in the document feels wrong to me, and both would be more confusing if the terminology were changed to 'defined type'. This isn't the spec, where the term has a precise meaning.

@go101

This comment has been minimized.

Copy link
Author

commented Jun 10, 2019

Why more confusing, is it more clearly instead?
After all, preciseness is not a bad thing.

On the other hand, this is not a big matter I think.
People should know what is the real meaning eventually.

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

Any "defined type" is also a "named type" so it's not completely wrong.

I'm coming to regret the term "defined type" - we had to introduce some term to distinguish between any type that has a name (which may be an alias), and what we now call a "defined type". But "defined" is so generic that it's not very clear, either.

A better choice might have been the term "nominal type" which has a technical meaning closer to what we want to express. But then I'm reluctant to change this again, everywhere.

Leaving the decision to @robpike . There's two (or three) places in the doc which would change from "named type" to "defined type".

@dmitshur dmitshur added this to the Go1.14 milestone Jun 10, 2019

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

I think it's clear as is and, as @griesemer notes, "defined type" is a little mysterious out of context.

Stet.

@robpike robpike closed this Jun 10, 2019

@go101

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

A little off topic, although the use of "named type" in Efficient Go doesn't need to be accurate, it should be accurate in some Go books, at least, the uses of some terminologies in those books should not conflict with Go specification.

For example, I ever used the named type terminology in my book, Go 101. I defined this terminology as defined types or type aliases. However, after reading one comment of @griesemer (sorry, I can't find out this comment now), I removed this terminology from my book, because Go specification never formally admit an alias is a type, and I'm afraid of Go specification will use a different definition for named type later.

I understand that naming is hard sometimes in programming world, and I understand that the introduction of type aliases increases the difficulty to describe something accurately and briefly sometimes. For example, the description of what types or aliases can be embedded still needs to be adjusted. But I think the sooner to finalize some descriptions and terminology definitions , the less confusions will be spread across the Go community.

@go101

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

[continued]
If type aliases shouldn't be called as types, then I think named type and define type are totally equivalent, so the description in Efficient Go is accurate. In fact, this is also my preferred definition. The definition avoids confusions in using the types/* packages.

So is it a mistake (and unnecessary) to rename the named type terminology to defined type since Go 1.9?

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

@go101 A type alias is simply a name denoting a type. Arguably, a type, such as []int, that has a name, such as intList, is a "named type" of sorts (it got a name, after all). But an intList which is an alias defined as

type intList = []int

is not the same as

type intList []int`

In the former, intList is a name denoting the type []int - intList and []int can be used interchangeably, they are identical. In the latter, intList is a name denoting a new type which happens to have the underlying type []int, but it is not (identical to) an []int. Still, in both cases one might (sloppily) talk about a "named" type: For the alias, the named type (with name intList) means []int. For the defined type, the named type (also with name intList) means the newly created defined type that we gave the name intList. When we have a defined type, the only way to refer to it is via it's name.

The point is, "named type" can be very confusing if not used precisely. Hence the term "defined type".

@go101

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

I understand all these, and I would make some supplements.

..., intList and []int can be used interchangeably,

There is an exception, when intList is embedded in a struct type.

... When we have a defined type, the only way to refer to it is via it's name.

We can also refer to it via its aliases, I think.

The point is, "named type" can be very confusing if not used precisely. Hence the term "defined type".

It is true that "named type" can be very confusing, but only if we don't provide it a clear definition. If we clearly specify that aliases can't be called as types (a.k.a., don't think alias declarations as type declarations), then "named type" can only be the current "defined types" described in Go spec (and vice versa).

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

ACK to the supplements.

I agree that if "named type" is used carefully, then it can only mean "defined type" (and vice versa). I'm not happy about "defined type" either (even though I suggested it, originally). In retrospect it's not clear that making the change was helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.