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

go/types: investigate representation of byte/rune as aliases #17656

Closed
griesemer opened this issue Oct 28, 2016 · 3 comments
Closed

go/types: investigate representation of byte/rune as aliases #17656

griesemer opened this issue Oct 28, 2016 · 3 comments

Comments

@griesemer
Copy link
Contributor

Tracking issue.

@griesemer griesemer added this to the Unreleased milestone Oct 28, 2016
@griesemer griesemer self-assigned this Oct 28, 2016
@griesemer
Copy link
Contributor Author

cc: @alandonovan

@alandonovan
Copy link
Contributor

alandonovan commented Nov 2, 2016

I can't see how this can be done without breaking the API.

In any case, the go/types API already uses a representation that deviates from the concepts of the spec in a couple of places. For example, a predeclared type like int is a named type, but is not represented by types.Named because... what would be its underlying type?. And unsafe.Pointer is a pointer type, but is not represented by types.Pointer because... what would be its element type? These design choices are clearly trade-offs but are not obviously wrong. Not representing rune and byte using types.Alias provides clients with the invariant that Alias.Orig returns a package-level const/var/func/type object.

@griesemer
Copy link
Contributor Author

Proposal #16339 was declined and the implementation removed.

@golang golang locked and limited conversation to collaborators Nov 5, 2017
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

3 participants