That is just the language definition. It is fine for an implementation to actually compare both at the same time as long as within the language you can not observe this happend. If we cant tell the read to be b happenend with a or before a (hello spectre) then for the implementation it should be fine to have done the comparison.
This is more of a constraint if the struct contains a comparison that can panic. The panic must happen in order or not at all depending how the fields are listed.
type t struct {
a int64
b any
}
Should not panic on b if a values are already different.
Note that afaik [3]string(s) was not valid before go1.20 so no existing code should use it. The semantic equivalent had to be written as *(*[3]string)(s) which also copies the array pointed to by *[3]string)(s). The new notation is basically a shorthand and easier to discover than using *(*[3]string)(s): https://github.com/golang/go/issues/46505
This is more of a constraint if the struct contains a comparison that can panic. The panic must happen in order or not at all depending how the fields are listed.
Should not panic on b if a values are already different.