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: Add support for retrieving function parameter names with reflect #12384

nenadl opened this issue Aug 28, 2015 · 4 comments


Copy link

nenadl commented Aug 28, 2015

Currently there is no way to retrieve function/method parameter names with the reflect package. The only introspection available is for the types of the input and output parameters of a function. The seems to be an exception with the reflect package, since it does offer naming information in most other cases.

When building RPC/API libraries it is useful to be able to retrieve these method parameters names for purposes of runtime schema output, input validation on unstructured data, and possibly some API semantics. There are some alternatives right now:

  • Parse the source and use code generation to compile this metadata into the running program.
  • Use structs for all input/output and then use the field names in the structs, along with their tags, for introspection.

Some other considerations:

  • I understand that this might lead to binary and/or memory size increase due to the additional metadata that might have to be stored. This change might not be ideal this far into the 1.X cycle, but I think it should at least be considered for 2.0.
  • A fairly straightforward way to do this, that would not break backwards compatibility, would be to add two methods to reflect.Type that would retrieve the In/Out parameter names by Index.

Apologies if this is a duplicate issues. I searched the forums (nuts/dev) and this issue tracker and could not find any previous issues filed on this topic.

Copy link

cespare commented Aug 28, 2015

It's a fairly significant change to allow code that depends on parameter names. Today, a library writer is free to change any parameter names in their API; with this change, the names would have to be considered part of the exported API and therefore the library author would be under some obligation never to change them.

Copy link

rsc commented Sep 3, 2015

Reflect provides information about types. Function parameter names are not part of the func type. In contrast, struct field names are. That is:

var f func(x int)
var g func(y int)
f = g // perfectly fine, same type

var s struct { x int }
var t struct { y int }
s = t // compiler error, not same type

Reflect provides access to struct field names because they are part of the type. Func parameter names are not.

I think it would likely be a mistake to expand the scope of package reflect beyond the clearly defined line of "types". It's not obvious to me where else to draw a line between func parameter names and the entire source files.

Also, because parameter names are not part of type checking and have a history of having literally no semantic meaning outside the function body and documentation, I'd be wary of enabling reflection-based programs that break when you rename a function parameter. People understand that renaming a struct field can break things, because struct fields can be referred to in other places in the source. No one expects that renaming a function parameter (and updating references in the function body) would break anything else.

Copy link

minux commented Sep 3, 2015 via email

Copy link

nenadl commented Sep 3, 2015

Caleb, I can see your point. It would definitely be something that people would have to watch out for in the future. If this feature is added to the reflect package then I don’t see how that additional “cognitive” burden of having to watch out for parameter changes and freeze API functions could be avoided. I don’t necessarily think that it would impact most people, but I can see how it could lead to some tricky issues between dependencies.

Russ, thank for your insight. I also read through the named parameters discussion that Minux referenced and it seems that both proposals present similar issues. I have a better appreciation of the problems involved here.

Obviously changing the definition of the function Type to include parameter names this late in the 1.x release is out of the question, and I don't even think that's necessarily a good idea. And I can see why you would be reluctant to expand the scope of the reflect package beyond Type information, especially without a clear boundary.

Minux thank you for the suggestion, I took a similar path here.

Taking all of your points into consideration, I think that this proposal would cause more complications than solutions. I'm going to close it for now, please re-open if you feel like additional discussion is warranted.

@nenadl nenadl closed this as completed Sep 3, 2015
@golang golang locked and limited conversation to collaborators Sep 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

6 participants