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: go/token: API That Checks Token for Predeclared Identifiers #29694

Closed
jcburley opened this issue Jan 11, 2019 · 8 comments
Closed

proposal: go/token: API That Checks Token for Predeclared Identifiers #29694

jcburley opened this issue Jan 11, 2019 · 8 comments

Comments

@jcburley
Copy link
Contributor

My current Go version is:

$ go version
1.11.4

I'm working on a kind of transpiler that reads Go packages and creates wrappers (including both new Go code and code in a dialect of Clojure) to call them.

"Canonicalizing" names into the target language means lowercasing them, so e.g. Foo becomes foo. Then, using that name within the generated Go code keeps things simple.

Unfortunately, Import becomes import, which is a reserved identifier in Go. Ditto Default, For, etc. These end up converted to reserved identifiers, which prevents their use as function names.

It's easy enough to detect and work around this (for now I'm prefixing such names with a single underscore).

But having 3rd-party code (like mine) try to keep track of reserved identifiers in Go suggests that maybe go/ast or some other library should offer an API that either returns the full list, an API that returns whether a given string denotes a reserved identifier, or both.

@gopherbot gopherbot added this to the Proposal milestone Jan 11, 2019
@ghost
Copy link

ghost commented Jan 11, 2019

This is already provided by go/token:

token.Lookup(str).IsKeyword()

@jcburley
Copy link
Contributor Author

Works great, thanks!!

I was searching the docs for "reserved", and didn't think to search go/token...maybe link to that API from https://golang.org/ref/spec#Keywords or someplace like that?

@jcburley
Copy link
Contributor Author

Hmm, this doesn't seem to catch built-in type names, like string, int, etc. And I don't see a go/token API that might do that.

Any ideas?

@jcburley jcburley changed the title Proposal: API That Returns Reserved Words Proposal: API That Checks Token for Reserved Keywords and/or Typenames Jan 11, 2019
@jcburley jcburley changed the title Proposal: API That Checks Token for Reserved Keywords and/or Typenames Proposal: API That Checks Token for Predeclared Type Names Jan 11, 2019
@jcburley jcburley changed the title Proposal: API That Checks Token for Predeclared Type Names Proposal: API That Checks Token for Predeclared Identifiers Jan 11, 2019
@julieqiu julieqiu changed the title Proposal: API That Checks Token for Predeclared Identifiers proposal: go/token: API That Checks Token for Predeclared Identifiers Jan 11, 2019
@ianlancetaylor
Copy link
Contributor

For the predeclared identifiers that are not keywords, you can check whether types.Universe.Lookup(id) returns non-nil. Eg., https://play.golang.org/p/S99MrEuINY4 .

@mdempsky
Copy link
Member

It's worth noting too that it's valid to shadow Go's predeclared identifiers, though obviously you should avoid that if you need access to the predeclared objects.

@jcburley
Copy link
Contributor Author

It's worth noting too that it's valid to shadow Go's predeclared identifiers, though obviously you should avoid that if you need access to the predeclared objects.

Yes -- access to the predeclared objects is required in all the cases that were throwing build-time errors!

@jcburley
Copy link
Contributor Author

For the predeclared identifiers that are not keywords, you can check whether types.Universe.Lookup(id) returns non-nil. Eg., https://play.golang.org/p/S99MrEuINY4 .

Perfect, thanks! Also worth documenting -- I had searched go/token and others for "universe" (based on the verbiage in the doc on predefined identifiers) but had come up empty, not having checked go/types.

@rsc
Copy link
Contributor

rsc commented Jan 16, 2019

It sounds like no new API is needed here.

@rsc rsc closed this as completed Jan 16, 2019
@golang golang locked and limited conversation to collaborators Jan 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants