[CamouflagedKiwi]

Because the order of fields can be significant. It's very relevant for syscalls, and is observable via the reflect package; it'd be strange if the field order was arbitrarily changed (and might change further between releases).

I assume the thinking was that this is pretty easy to optimise if you care, and if it's on by default there'd then have to be some opt-out which there isn't a good mechanism for.

[9rx]

> and if it's on by default there'd then have to be some opt-out which there isn't a good mechanism for.

Good is subjective, but the mechanism is something already implemented: https://pkg.go.dev/structs#HostLayout

[CamouflagedKiwi]

Oh interesting, I've not encountered that before - I suppose because it is currently the default behaviour.

What I was hoping not to find (and fortunately didn't!) was one of Go's magical syntactic comments.

[kbolino]

In particular, struct field alignment matches C (even without cgo) and so any change to the default would break a lot of code.

[9rx]

> struct field alignment matches C (even without cgo)

The spec defines alignment for numeric types, but that's about it. There is nothing in the spec about struct layout. That is implementation dependent. If you are relying on a particular implementation, you are decidedly in unsafe territory.

> so any change to the default would break a lot of code.

The compiler can disable optimization on cgo calls automatically and most other places where it matters are via the standard library, so it might not be as much as you think. And if you still have a case where it matters, that is what this is for: https://pkg.go.dev/structs#HostLayout

[kbolino]

That's good to know. I'm not making use of this assumption, but the purego package (came from ebitengine) does. It looks like they're aware of HostLayout [1] but I'm not sure how many other people have gotten the memo (HostLayout didn't exist before Go 1.23).

[1]: https://github.com/ebitengine/purego/issues/259

[arp242]

> There is nothing in the spec about struct layout

De-facto a lot of programs rely on it, so whatever the spec says is irrelevant.

Not just for cgo by the way, but also things like binary.Read()/Write().

[9rx]

> but also things like binary.Read()/Write().

binary.Read/Write already uses reflect as far as I can tell, so it wouldn't matter in that case. There is an optimization for numeric values in there, which may be what you are thinking of? But they are specified in the spec and that's not what we're talking about anyway (and if an optimization really had to go, for whatever reason, it wouldn't be the end of the world).

Did you mean something else?

[kbolino]

I had to think about this one a bit.

Basically, binary.Read/binary.Write are capable of reading/writing struct values. The worry would be that, if the Go compiler reordered fields under the hood, the order may differ between writing the data and reading it back (especially across different versions of Go).

However, because these functions use reflection, they likely wouldn't be affected. While the in-memory layout of the struct fields might get reordered, presumably the reflection order would match the declaration order. Indeed, there is already an Offset field on the reflect.StructField type, and there is no statement anywhere I can find that such offsets must increase monotonically.

So, the fields would remain in declaration order when inspected with reflection, but their offsets could jump around within the struct, yet well behaved reflection-based code should be agnostic to this change.

[int_19h]

This is very unfortunate, since most structs are never going to be passed to C, yet end up paying the tax anyway. They really should have made it opt-in.