nfields is easily misused and can lead to bugs

[KristofferC]

Here is a struct for a bitmap header

struct BitmapHeader
    signature               :: UInt16
    bmp_size                :: UInt32
    reserved_1              :: UInt16
    reserved_2              :: UInt16
    imag_data_offset        :: UInt32
    size_bitmap_info_header :: UInt32
    width                   :: UInt32
    height                  :: UInt32
    n_planes                :: UInt16
    bits_per_pixel          :: UInt16
    compression_type        :: UInt32
    image_size              :: UInt32
    horizontal_resolution   :: UInt32
    vertical_resolution     :: UInt32
    n_colors                :: UInt32
    n_important_colors      :: UInt32

    r_mask                  :: UInt32
    g_mask                  :: UInt32
    b_mask                  :: UInt32
    meh                     :: UInt32
end

We want to compute the packed size (no padding) so we write something like

function sizeof_packed(h::Type{BitmapHeader})
   sum(sizeof(fieldtype(BitmapHeader, i)) for i in 1:nfields(BitmapHeader))
end

and it seems to work fine

julia> sizeof_packed(BitmapHeader)
70

There is however a terrible bug here which can be made obvious with:

julia> struct Foo end

julia> nfields(Foo)
20

😱 We are getting the number of fields inside the DataType object (which in this case happened to be the same number as the fields inside BitmapHeader.) Adding fields to BitmapHeader will now lead to (likely silent bugs).

The correct function we should have used is fieldcount.

julia> fieldcount(Foo)
0

The problem here is:

• It is hard to know in general whether reflection-functions operates in the value or type domain. We now for example have isbitstype and isbits that helps with this. Having nfields(x) and fieldcount(x) give different answers is error prone.
• nfields(::DataType) is just almost never what you want. These are internal fields so having some internal function for getting that count wouldn't be too bad.

[JeffBezanson]

This is why there are doc strings. Ok to propose new names for these though, which can even be introduced in 1.x.

[StefanKarpinski]

Why not just delete nfields? fieldcount(typeof(x)) is the unambiguous way to do this.

[JeffBezanson]

That would prevent us from having variable length objects.

[StefanKarpinski]

Ah, I see. That makes sense.

[o314]

Are this kind of expando so common ?

The only references to variable length objects i found in julia github were for simplevector and interop with fortran string ... Not so many it seems

[StefanKarpinski]

Not so many it seems

Currently.