Ability to perform reflection on function parameters

[VisenDev]

It is possible to reflect on the types of functions but not their names using @typeInfo(function).Fn.params. It would be useful if we had some way of accessing the names of these parameters as well, such as @paramInfo(function)

The specific use case for parameter name reflection is generating luadoc comments from zig functions. See natecraddock/ziglua#94

The ability to perform compile time reflection on parameter names would probably also be useful for any other projects that are generating cross-language bindings or documentation

[VisenDev]

The way I understand, this would require functions of differing argument names to result in different types. Currently function types compare equal regardless of argument names (and can be declared without any argument names whatsoever). IMO this would be quite a substantial change, and I personally don't think it's worth it.

I see how that would be the case for implementing this via @typeInfo, hence why I suggested creating a different builtin that doesn't care about types and just returns an array parameters with their names and types -> @paramInfo(function)

[rohlem]

The way I understand, this would require functions of differing argument names to result in different types. Currently function types compare equal regardless of argument names (and can be declared without any argument names whatsoever). IMO this would be quite a substantial change, and I personally don't think it's worth it.

I see how that would be the case for implementing this via @typeInfo, hence why I suggested creating a different builtin that doesn't care about types and just returns an array parameters with their names and types -> @paramInfo(function)

Ah, my bad, it seems I didn't properly read that line.
In that case I definitely agree that having additional builtins would be the way to go.
Maybe as with @typeInfo we could try a single @srcInfo builtin that returns a union of struct-s to get different information based on the type of entities/declarations inspected.
I still wonder when operating on the AST would be more appropriate - but I don't see the downside in exposing as much information as possible to comptime either.
It would almost certainly be a simpler, more stable and more comfortable interface to use.
(Makes me wonder how far such a feature could even simplify / decouple Zig's own autodoc process.)

[VisenDev]

I still wonder when operating on the AST would be more appropriate

For certain use cases in might be, but this adds a lot of complexity

• but I don't see the downside in exposing as much information as possible to comptime either. It would almost certainly be a simpler, more stable and more comfortable interface to use.

Yes I agree, needing to reparse your source code in order to do reflection is not an ideal interface. If the compiler has this information already - why not provide in comptime and save the trouble?