proposal: Add support for retrieving function parameter names with reflect

[nenadl]

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.

[cespare]

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.

[rsc]

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.

[minux]

As mentioned in the recent named parameter proposal, I think one solution to your RPC/API library problem is to define inline (anonymous) parameter structs as function parameter. e.g. func (r *State) MethodA(args struct { Arg1 int; Arg2 string }) error { // use args.Arg1, args.Arg2, etc. } And then reflect should be able to pick up the names easily. Because these RPC methods are only intended to be called indirectly using reflect, having anonymous struct as sole argument won't complicate anything.

[nenadl]

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.