# Why will we have to say fieldnames(typeof(v)) instead of fieldnames(v)?

**URL:** <https://discourse.julialang.org/t/why-will-we-have-to-say-fieldnames-typeof-v-instead-of-fieldnames-v/9129>\
**Category:** General Usage\
**Created:** [February 17, 2018, 3:58pm UTC](https://discourse.julialang.org/t/why-will-we-have-to-say-fieldnames-typeof-v-instead-of-fieldnames-v/9129 "2018-02-17T15:58:44Z")\
**Posts on this page:** 1\
**Showing post:** 29

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [February 18, 2018, 2:14pm UTC](https://discourse.julialang.org/t/why-will-we-have-to-say-fieldnames-typeof-v-instead-of-fieldnames-v/9129/29 "2018-02-18T14:14:48Z")

</div>

Julia’s dispatch mechanisms allow you to define different implementations based on the input type, but the guiding principle should be that all the methods for a given function should _mean_ the same thing. Obviously that’s pretty loosely-defined, so I try to think about what the help string for a given generic function should be, and minimise the number of “except when” clauses you’d need.

So in this case it seems like the new behavior is “`fieldnames(x)` returns a list of the fields of `x`”. You’re arguing for

“`fieldnames(x)` returns a list of the fields of `typeof(x)`. `fieldnames(x::Type)` returns the fields of `x`.”

This sort of punning is discouraged because while it may make things more convenient when you know a prori the type of `x`, it makes it harder to write generic code that means the same thing regardless of the type of `x`.

---

_[View the full topic](https://discourse.julialang.org/t/why-will-we-have-to-say-fieldnames-typeof-v-instead-of-fieldnames-v/9129)._
