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

Proposal: better name for *ast.File fields #40058

amarjeetanandsingh opened this issue Jul 5, 2020 · 2 comments

Proposal: better name for *ast.File fields #40058

amarjeetanandsingh opened this issue Jul 5, 2020 · 2 comments


Copy link

@amarjeetanandsingh amarjeetanandsingh commented Jul 5, 2020

What version of Go are you using (go version)?

go version go1.13.4 darwin/amd64

What did you do?

The Package and Name fields of *ast.File struct are a bit confusing.

It was an effort just to get the name of Package of a *ast.Field object because I thought *.ast.File.Name will be the name of the file. It was so obvious that I didn’t though of looking at the comments.
Thanks to Rui Santos for helping me out. Later I saw it was written in comments Name is Package name, not the file name.

What did you expect to see?

  • Instead of Name, something like PkgName would be better because it contains the package name of that file.
  • Instead of Package, maybe PkgPos can be more helpful name because it contains token Pos.

What did you see instead?

  • *ast.File.Name field containing the package name of the file is not intuitive.
  • *ast.File.Package field contains a Pos of package, so it's difficult to understand .

If it's there, I guess there must be some reason to name those fields like that, what I am unaware of.
But it was confusing for me.

Even if we decide to rename the fields, i think it won’t be that straight forward because it will start breaking the older versions.

Please share your thoughts.

/cc @rsc @griesemer

@gopherbot gopherbot added this to the Proposal milestone Jul 5, 2020
@gopherbot gopherbot added the Proposal label Jul 5, 2020
Copy link

@ianlancetaylor ianlancetaylor commented Jul 5, 2020

They may be bad choices, but any change now would break the Go 1 compatibility guarantee (

Copy link

@davecheney davecheney commented Jul 6, 2020

Based on 👍 from the OP closing as answered.

@davecheney davecheney closed this Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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