Reflect Type.Field() order

Question

I can't seem to find it in documentation, is there any guarantee that the order from the fields will match the order declared in the struct? I know it seems like it would logically (due to memory layout),and it seems to perform this way too, but just making sure. I don't want code to break later on if this isn't a guarantee.

For example, if I had

type Foo struct {
    bar    string `tag:"bar"`
    baz    string `tag:"baz"`
    barbaz string `tag:"barbaz"`
}

and I ran this code:

var c Foo
t := reflect.TypeOf(c)
nf := t.NumField()

tags := make([]string, nf)

for f := 0; f < nf; f++ {
    tags[f] = t.Field(f).Tag.Get("tag")
}

Would tags be guaranteed to be ["bar", "baz", "barbaz"]?

Miley

Would Value.FieldByName help in your case? – Beech

I just wanted the tag names for something, it was more me being a lazy programmer and trying to do a little less coding (which always turns into a ton more work it seems). I don't know if I am going to stick to that method anymore, now I am just kinda interested in the answer. – Miley

Even though GC (the standard Go compiler) and GCCGO don't reoder struct fields, I wouldn't rely on any ordering. There are no express guarantees in the documentation. – Landfall

Maybe this is a silly question but how do you know they don't reorder struct fields? Also (with the risk of asking too much in a comment) would it ever be considered advantageous for them to do so? I don't know much about compiler design. – Miley

It can be advantageous if you can achieve memory alignment by just reordering the fields instead of adding padding in between them. – Landfall

Do you want to add your first comment as an answer so people at least know they can get some info out of this? – Miley

Answer 1

Even though GC (the standard Go compiler) and GCCGO don't reoder struct fields today, I wouldn't rely on any ordering. There are no express guarantees in the documentation. This might be done in a future version of either compiler.

Field reordering is a technique used to memory-align fields inside of a struct without resorting to padding (unnecessarily inflating the struct's memory representation). You can read about it in the following question:

Why can't C compilers rearrange struct members to eliminate alignment padding?

Landfall

Answer 2

I asked on golang-nuts about this, and got an answer from Ian Lance Taylor confirming it's declaration order, and will not change.

It's the order in which the fields appear in the struct declaration. It's not going to change. If you find a case where it is not the order in the declaration, please file a bug. Thanks.

Asci