Undocumented "fields"?

General Usage
1

in docs, I see the following:

eltype_wrong(::Type{A}) where {A<:AbstractArray} = A.parameters[1]

the .parameters, though I can guess what it is, it’s an undocumented “field” of type parameters. I wonder if there’s any other hidden fields? a small section about these “fields” in doc would be fine. thanks.

1 Like
2

Those fields are implementation details, and the purpose of that example (note the name eltype_wrong) is to demonstrate that one should not be using that sort of introspection, exactly because you cannot rely on the field even existing:

One common mistake is to try and get the element-type by using introspection:

eltype_wrong(::Type{A}) where {A<:AbstractArray} = A.parameters[1]

However, it is not hard to construct cases where this will fail:

struct BitVector <: AbstractArray{Bool, 1}; end

Here we have created a type BitVector which has no parameters, but where the element-type is still fully specified, with T equal to Bool !

3 Likes
3

Also, you can overload these access too, check : getfield / setfield! and getproperty / setproperty! .

4

oic. propertynames(::Type, true) gives the list of “hidden” fields:

julia> propertynames(Float64, true)
(:name, :super, :parameters, :types, :names, :instance, :layout, :size, :ninitialized, :uid, :abstract, :mutable, :hasfreetypevars, :isconcretetype, :isdispatchtuple, :isbitstype, :zeroinit, :isinlinealloc, :has_concrete_subtype, Symbol("llvm::StructType"), Symbol("llvm::DIType"))
2 Likes
5

They are not “hidden” — see the devdocs.

It is just bad style to rely on them outside Base, and unless you really need to. Usually you don’t, unless you are working on the language internals.

1 Like