-
Notifications
You must be signed in to change notification settings - Fork 17.4k
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: types.aliases should be exported #22628
Comments
You can use |
That was fast :) |
Thanks for the workaround. However, the documentation point has yet to be addressed. |
Robert, how about something like this?
|
Sure, sounds good. What's also missing is a doc string for Universe (and Unsafe, while there). Care to send a CL? Or should I do it? |
Apologies for closing early - had not noticed the point on the docs. |
Some suggestions for the doc wording:
Typ is a slice, technically. The doc comment should start with the declaration's name.
It would perhaps be clearer to say that Rune and Int32 are equal, and Byte and Uint8 are equal, and thus in Typ, Rune and Byte correspond with the Basics for Int32 and Uint8, respectively.
It might be unclear how these Basics don't represent the alias types, since they're technically equal and interchangeable from a type checking point of view. Perhaps it would help to point out how the names for those Basics won't match what's assumed for the Rune and Byte kinds. Altogether, perhaps something like this: // Typ contains the canonical Basic for a BasicKind. Since Byte and Rune
// are aliases, the Basics they correspond to do not have matching names.
// To get the Basics for them with matching names, use Universe.Lookup(name).Type().
var Typ = []*Basic{ ... In any case, thanks for documenting it! |
Change https://golang.org/cl/85075 mentions this issue: |
To be clear, this is:
Otherwise, there's no pre-defined way to get a Basic value whose
String()
is "rune". This means you can't get a type, convert it into an equivalent representation, and then convert it back into an equivalent types.Type with the sameString()
. Simulating the byte/rune types with Named types doesn't work in general because byte/rune can be underlying types, and Named.SetUnderlying will panic if you use a Named argument.It's implied that all the Basic values are in Typ, but the Basic value you get for byte/rune types isn't. The Typ documentation should warn about this.
The text was updated successfully, but these errors were encountered: