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

Open
go101 opened this issue Oct 23, 2019 · 6 comments
Open

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

go101 opened this issue Oct 23, 2019 · 6 comments

Comments

@go101
Copy link

@go101 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.
@go101
Copy link
Author

@go101 go101 commented Oct 25, 2019

@griesemer @robpike how do you think?

@griesemer
Copy link
Contributor

@griesemer 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 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

@ianlancetaylor ianlancetaylor commented Oct 29, 2019

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

@griesemer griesemer commented Oct 29, 2019

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

@go101
Copy link
Author

@go101 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.