composite types and fieldnames

[Tamas Papp]

Hi,

I thought I would ask before reporting as a bug.

If isa(T, DataType) but !Base.isstructtype(T), is fieldnames(T) supposed
to return an empty vector or throw an error?

Currently (v"0.4.0-dev+4524") the first one happens:

julia> fieldnames(Real)
0-element Array{Symbol,1}

julia> fieldnames(Float64)
0-element Array{Symbol,1}

But the error message in the code

function fieldnames(v)
t = typeof(v)
if !isa(t,DataType)
throw(ArgumentError("cannot call fieldnames() on a non-composite type"))
end
return fieldnames(t)
end

suggests that this is not what is supposed to happen. Would submit a PR,
but I need to wrap my head around variations of DataType and how to
interpret the fields. Would it make sense to extend the type hierarchy
with something like

CompositeType <: DataType
MutableType <: CompositeType
ImmutableType <: DataType
AbstractType <: DataType

?

Best,

Tamas

[Jameson Nash]

There used to be lots of different types of Type, but now everything is just an instance of a DataType. The properties of that datatype might vary (isbitstype, isstructtype, ismutable, isabstract, isleaftype, etc.), but it doesn't require a new type of Type to reflect those distinctions, a simple flag is enough.

[Tamas Papp]

Thanks for clarifying.

So is it intentional that fieldnames is defined for non-composite types,
returning an empty vector?

Best,

Tamas

[Jameson Nash]

Yes, it is reusing the common structure; a bitstype is a type with a non-zero sizeof but no fields. 

On Fri, May 1, 2015 at 9:57 AM Tamas Papp <tkp...@gmail.com> wrote:

[Toivo Henningsson]

Is that behavior actually useful somewhere. If I all for the last of field names I'd expect that those fields describe all the data stored in the type, so it would seem safer to throw an error if that is an option.