https://doc.rust-lang.org/reference/type-layout.html#the-c-r...
You have to specify this behavior with #[repr(C)]. Otherwise, the compiler will rearrange fields to try to optimize packing and alignment.
Does not currently do what ?
Rust certainly will re-arrange the layout of a default repr(Rust) struct to make it smaller, for example: https://rust.godbolt.org/z/7KsqvnE9o
[Edited to provide a nicer Godbolt example which compares the two layout strategies]
[0] https://github.com/bootreer/vroom/blob/37bd8a22f5e0550b2cbc9... [1] https://doc.rust-lang.org/reference/type-layout.html#the-ali...
https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/fie...
If you need binary-compatibility with C structs in Swift, you can define them in a bridging header.
Does Rust fundamentally guarantee that if you make a struct, its fields will lay out in memory in the order that you defined them? Can it be used to interact with APIs (really ABIs) who expect a C struct (or pointer to one)?
I think my main frustration with stuff like Go and Swift in this case is that their structs are not binary-compatible with C structs in this way because they rearrange things to be better aligned/packed/whatever.