# 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:** 43

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [February 19, 2018, 12:41pm UTC](https://discourse.julialang.org/t/why-will-we-have-to-say-fieldnames-typeof-v-instead-of-fieldnames-v/9129/43 "2018-02-19T12:41:13Z")

</div>

> [@DNF](#):
>
> If A and B can clearly be determined, that resolves the ambiguity, and that is the case here (you can always tell if the input is a type, or not–well, that is what I assume.)

This is a logically, well, trivial statement since if A and B are the two sets that were ambiguous (i.e. they intersects), you can always make two new sets A’ and B’ by assign the intersection of A and B to A.

In another word, (repeat almost exactly what I’ve said above) just because you can make an unambiguous definition on top of an ambiguous one does not means the ambiguity is not there. If it is allowed to add arbitrary qualifiers to the condition (i.e. adding non-type condition of fieldnames on values) then ambiguity will never be a valid argument for anything, ever. Since this doesn’t seem to be what you suggest, you have to use the original definition of A and B (that do not have arbitrary qualifier applied) and in that case they are clearly ambiguous.

---

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