# Is there anyway to get function and arg idents at comptime?

**URL:** <https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382>\
**Category:** Help\
**Tags:** comptime\
**Created:** [June 27, 2026, 11:41am UTC](https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382 "2026-06-27T11:41:51Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shrimo](https://ziggit.dev/letter_avatar_proxy/v4/letter/s/6a8cbe/32.png) [@Shrimo](https://ziggit.dev/u/Shrimo)\
**Post date:** [June 27, 2026, 11:41am UTC](https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382/1 "2026-06-27T11:41:51Z")

</div>

The current `Fn` struct only stores type and attribute info.

Perhaps something like `@hasDecl` / `@hasField` for function/param names.

---

<div class="post-metadata">

**Author:** ![vulpesx](https://ziggit.dev/user_avatar/ziggit.dev/vulpesx/32/3989_2.png) [@vulpesx](https://ziggit.dev/u/vulpesx)\
**Post date:** [June 27, 2026, 11:42am UTC](https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382/2 "2026-06-27T11:42:51Z")

</div>

nope (ten character requirement)

---

<div class="post-metadata">

**Author:** ![Shrimo](https://ziggit.dev/letter_avatar_proxy/v4/letter/s/6a8cbe/32.png) [@Shrimo](https://ziggit.dev/u/Shrimo)\
**Post date:** [June 27, 2026, 11:44am UTC](https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382/3 "2026-06-27T11:44:50Z")

</div>

rough (ten character requirement)

---

<div class="post-metadata">

**Author:** ![castholm](https://ziggit.dev/user_avatar/ziggit.dev/castholm/32/1330_2.png) [@castholm](https://ziggit.dev/u/castholm)\
**Post date:** [June 27, 2026, 1:19pm UTC](https://ziggit.dev/t/is-there-anyway-to-get-function-and-arg-idents-at-comptime/16382/4 "2026-06-27T13:19:32Z")

</div>

Further context:

> <https://github.com/ziglang/zig/issues/6534>
>
> Similar reasoning as ability to access doc comments with reflection. Too many wa…ys to make confusing code. We don't want people reading code to have to wonder in the back of their minds if naming a function parameter a certain way would have a meaningful change.
> 
> related: #6530

Parameter names are effectively documentation comments (from the caller’s point of view). I don’t know what your use case but see mlugg’s comment near the bottom of the linked issue which suggests using regular structs as parameters if you need a name that you can reflect on.