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: suggest: restrore the "defined type" terminology to "named type". #35091

Closed
go101 opened this issue Oct 23, 2019 · 9 comments
Closed

doc: suggest: restrore the "defined type" terminology to "named type". #35091

go101 opened this issue Oct 23, 2019 · 9 comments
Labels
Documentation ExpertNeeded FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@go101
Copy link

go101 commented Oct 23, 2019

Since the introduction of type alias, most places of using the old terminology named type are changed to defined type, to avoid some supposed confusions. Now it looks the old terminology named type is intended to be used to represent defined types or type aliases, but this is not confirmed in any official Go document.

However, this change brings some embarrassing situations, and causes some inconveniences in explaining some concepts.

IMHO, I think this change is not very necessary. We can re-clarify that if we say a type alias T is a named type, we actually means the type represented by the alias T is a named type. If T represents an unnamed type, we should never say T is a named type, even if the alias T itself has a name.

If most people think my opinion is reasonable, I think it is still not too late to restrore the defined type terminology to named type now, for the terminology defined type is still not used widely but the terminology named type is still used widely.

In short, the benefits of this suggestion:

  • avoids the embarrassing situation mentioned above
  • avoids causing some inconveniences in explanations.
  • keep many many old documents/tutorials/apis still legal.
@dmitshur dmitshur added ExpertNeeded NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 23, 2019
@go101
Copy link
Author

go101 commented Oct 25, 2019

@griesemer @robpike how do you think?

@griesemer
Copy link
Contributor

griesemer commented Oct 28, 2019

I'm concerned that switching back is only going to increase confusion. I leave this open for now so others can chime in, but there's no urgent need to change this.

I agree that defined type is not great, but named type is not great either in the presence of alias types. It is difficult to argue that T as declared in type T = struct { f int } [corrected] doesn't have a name (clearly it does have the name T) and thus is not a named type (if it has a name, why is it not a named type?).

@go101
Copy link
Author

go101 commented Oct 29, 2019

@griesemer Did you mistype type T = struct { f int } as type T struct { f int } in your last comment?

I think we can avoid calling aliases as types and only say aliases represents types to rationalize the restore.

@ianlancetaylor
Copy link
Contributor

Aliases are definitely types. You can use an alias anywhere you can use any other type. I think that to say that aliases are not types would just make these concepts more complicated.

@griesemer
Copy link
Contributor

@go101 Yes, it should have been type T = struct { f int }. Corrected.

@go101
Copy link
Author

go101 commented Oct 29, 2019

@ianlancetaylor Comparing to Go 1.8, it is surely a little more complicated. It is hard to get a perfect solution. Personally, I think it is better than the defined type solution, because keeping old documents/tutorials/apis still valid is a big benefit.

@go101
Copy link
Author

go101 commented Mar 16, 2022

As Go 1.18 added back the named type terminology, I will this issue soon.

@go101 go101 closed this as completed Mar 16, 2022
@griesemer
Copy link
Contributor

@go101 A named type is not the same as a defined type.

@go101
Copy link
Author

go101 commented Mar 17, 2022

I understand. After all, the problems mentioned in this issue have gone with the change.

@golang golang locked and limited conversation to collaborators Mar 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation ExpertNeeded FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants