The Ziig language reference Documentation - The Zig Programming Language explicitly says that the order of fields in the ABI implementation of a struct with .autoContainerLayout can be anything.
// Zig gives no guarantees about the order of fields and the size of
// the struct but the fields are guaranteed to be ABI-aligned.
But are the elements of the @typeInfo(MyStruct).Struct.fields array guaranteed to be in declaration order? I cannot find a definitive answer. Any help or hint is highly appreciated.
I can’t find any official word about it in any official documentation, but I’m fairly confident that when you use @typeInfo to reflect on a type, the order of fields, decls and other members is guaranteed to be the same as the order they were declared in source.
At the very least, the compiler has behavior tests that assert that the order is correct:
This comment refers to the way struct fields are laid out in memory; it doesn’t say anything about the ordering returned by comptime reflection functions such as @typeInfo.
In practice, I’d expect things like this (i.e. ordering of .Struct.fields) to fall into a broad category of “unspecified, but requiring deliberate effort to change and thus exceedingly likely to remain as-is.” The test cited by @castholm provides weak evidence to bolster this assumption, although it looks to me more like a very general check that ensures reflection on structs works at all, not that it returns fields in any particular order.
Considering the language is still in 0.x and breaking changes are expected with every release, I wouldn’t think that relying on .Struct.fields ordering would make your code any less robust.
This is precisely my point. The reference manual does not say anything about the order of elements in the .Struct.fields array one way or another. Thanks to Order of fields in the `.Struct.fields` array - #2 by castholm response the behavioral tests seem to answer the question in affirmative.
I just remember reading an issue or pr a long time ago, that was about fixing the field and declaration order to be in order of how they appear in source code and that this was deliberately implemented, partially because before a lot of code did manual sorting to get a stable order that doesn’t change from compile to compile and with a predictable order that code could be removed, but I don’t remember the details or how it was called.
I tried searching in the closed issues but didn’t find it, maybe using blame on code that deals with struct formatting would show something related to that, or maybe somebody who has worked on that can point us to it.
Type information of structs, unions, enums, and error sets has fields which are guaranteed to be in the same order as appearance in the source file.
Type information of structs, unions, enums, and opaques has declarations, which are also guaranteed to be in the same order as appearance in the source file.
So in Zig 0.8.1 the order of declarations was unspecified and in the later versions it was also guaranteed, I think that was what I was vaguely remembering reading about.
