Should fieldnames return a tuple rather than an array?

[nalimilan]

It would sound natural to me for fieldnames to return a tuple. The current implementation returning an array implies an allocation even in cases where it could be avoided.

This could have more visible consequences now that we have NamedTuple, for which it is more common to extract the field names since they cannot be known in advance. EDIT: this comment doesn't seem accurate (see below)

[vtjnash]

Reflection on fieldnames is discouraged. (for NamedTuple, the keys should be extracted with the keys function).

[yurivish]

Reflection on fieldnames is discouraged.

Could you clarify what you mean here? I'm not sure if you meant something specific to NamedTuples or if it's discouraged to use fieldnames for metaprogramming in general.

[nalimilan]

Conversely, what are typical use cases for fieldnames?

[smldis]

The small story about this is that the issue is coming from slack, a user posted it as a note and there where some thumbs up and no thumbs down. I would rather let some core developer discuss the consecuences (and tradeoffs) of a deprecation for 0.7 and a switch for 1.0 or for the next major api break.
Please don't be noisy on the topic since it is difficult to take care of such a breaking change at this precise time.

[andyferris]

Reflection on fieldnames is discouraged.

If that's true in general (not specifically for named tuples) then we shouldn't be exporting it from Base, should we?

[vtjnash]

We export lots of reflection toys from Base. I suppose we could hide them under some sort of Reflection module, but many of them (isbits, names, fieldoffset, etc.) are pretty useful, and all are pretty varied.

(For NamedTuples, this is also just an artifact of their current implementation, not part of their stable API)

[yurivish]

The reflection tools are very useful for building good tooling; it would be sad to see them go away.

Would maybe marking them "unstable" suffice, if the concern is that there are rough edges that would require breaking changes in a 1.x?

[nalimilan]

These considerations don't seem to directly address the issue at hand, do they? What do we expect people to use fieldnames for exactly?

[smldis]

Looking at master they are mostly used for testing and documentation.
As for other usecases:

julia master (cholmod.jl):

let offset = fieldoffset(C_Sparse{Float64}, findfirst(name -> name === :stype, fieldnames(C_Sparse{Float64})))

gadfly (chain method)

for name in fieldnames(Data)
    #more code
    getfield(data, name)
    #more code

So @vtjnash a Reflection module would be a nice occasion to put some engineering love in the julia reflection toolbox.
Is this feasible given the release and man power constraints, before or after 1.0?

The toolbox for now is composed by more than just: isbits, names, fieldoffset, fieldname,fieldnames, getfield, methods, methodswith, subtypes

The currently exported methods list is not structured ordered by usecase/functionality (the work could start from here right?)

# types
    convert,
    # getproperty,
    # setproperty!,
    fieldoffset,
    fieldname,
    fieldnames,
    fieldcount,
    isconcrete,
    oftype,
    promote,
    promote_rule,
    promote_type,
    subtypes,
    instances,
    supertype,
    typeintersect,
    typejoin,
    widen,

#= ... =#

# help and reflection
    apropos,
    edit,
    code_typed,
    code_warntype,
    code_lowered,
    code_llvm,
    code_native,
    fullname,
    functionloc,
    isconst,
    isinteractive,
    less,
    method_exists,
    methods,
    methodswith,
    module_name,
    module_parent,
    names,
    varinfo,
    versioninfo,
    which,
@isdefined,

If this is the case, I'd link the discussion to #20555.
If it is not this issue is still addressable by finding an answer to the issue title.

[JeffBezanson]

I do think it would make sense for fieldnames to return a constant, immutable container. It tends to be small, and it would be weird to mutate it, so we might as well avoid the allocation.

[nalimilan]

Opened #25725.