Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
doc: Effective Go contains a use of "named type", which is an obsoleted terminology. #32496
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".
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
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.
So is it a mistake (and unnecessary) to rename the
@go101 A type alias is simply a name denoting a type. Arguably, a type, such as
type intList = int
is not the same as
type intList int`
In the former,
The point is, "named type" can be very confusing if not used precisely. Hence the term "defined type".
I understand all these, and I would make some supplements.
There is an exception, when
We can also refer to it via its aliases, I think.
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).
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.