-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
reflect: Type.Name and Type.String expose "link name" mangling of type arguments #55924
Comments
Another distinction: GOEXPERIMENT=unified supports defined types that are declared within type-parameterized functions, which implicitly parameterize the defined type. The implicit type arguments are relevant to type identity, so they need to be included in the link name. But they're also currently included in the reflect name, for the same reason as above: https://go.dev/play/p/ORCQud4MPp6?v=gotip (The mangling used is I've thought it might be better/clearer if local types were given reflect names like |
My expectation was always that for a generic type |
I think the function of reflect and go is a bit unrelated.
For example, you can define the type in the key of the map:
There is also no need to use too much type conversion in the code
The current reflect doesn't do anything like this:
With the current functionality, you can't do something with |
The type parameters proposal (https://go.googlesource.com/proposal/ /refs/heads/master/design/43651-type-parameters.md#reflection) states:
It's ambiguous what "name" should be used. Also, whether only reflect.Type.String should have been affected, or reflect.Type.Name too.
cmd/compile generates two names for each type: a "link name" that corresponds to type identity (so the linker can deduplicate it against other identical types), and a "reflect name" that's simplified somewhat for user presentation via reflect APIs.
However, for instantiated types' reflect names, it currently uses the link names of the type arguments. For example: https://go.dev/play/p/JAP28idHc9z
Can/should we change this behavior?
Some noteworthy distinctions:
=
byte to identify embedded fields./cc @rsc @ianlancetaylor @griesemer @golang/compiler
The text was updated successfully, but these errors were encountered: