Structs, C ABI + always the most optimized field arrangement?

[PaperPrototype]

Is it possible to satisfy optimized field arrangement without re-ordering fields at compile time?

Yes.

Just force the developer to align fields in an optimized order, and throw a compiler error if they don't.

Why do this? I'm not sure exactly what the C ABI is, but I do know it has to do with field re-ordering in structs. It would be nice if Golang could comply with the C ABI, making it much easier to use Golang alongside C.

Go fmt could automatically re-order fields for the developer on save to prevent the mental overhead of field re-ordering.

[avivcarmis]

Nice. I do have one thought. It would be annoying if fmt automatically changes the order for you. I can think of use cases where the ordering of fields has meanings other than memory consumption optimization (anything that's based on reflection for that matter). In such cases you do not want any tool to automatically override your decisions.

I suggest adding it to the compiler options, as suggested in this issue by @marcelloh. We could have compiler options (similar to typescript's for example) and set it there.

WDYT?

[PaperPrototype]

Nice. I do have one thought. It would be annoying if fmt automatically changes the order for you. I can think of use cases where the ordering of fields has meanings other than memory consumption optimization (anything that's based on reflection for that matter). In such cases you do not want any tool to automatically override your decisions.

I suggest adding it to the compiler options, as suggested in this issue by @marcelloh. We could have compiler options (similar to typescript's for example) and set it there.

WDYT?

Yeah I agree. Given the fact we will be transpiling to golang, it makes the most sense.

Also given the fact we would transpile to golang, the C ABI problem would not be solved since we would still have to find a way to force the GO compiler to respect our field ordering.

[marcelloh]

I would suggest to do it on compile time and not force the developer to write it in an optimal way. The reason behind this is that the struct might be written in a way that makes it readable (sorted, or ID field first and such) Sources are for humans after all. But to optimise it when compiling would be ideal. The developer won't notice a thing but the program is compiled in a more efficient way.

[avivcarmis]

@marcelloh this is not completely true. Everything based on reflection would be affected. For example the order that would be produced in json.Marshal gets reshuffled, in some cases it may hurt what the developer is trying to achieve. Personally, I wrote an internal library that generates web forms from go structs. The ordering of the fields in the form was derived from the ordering of the fields in the struct. In such a case, I'd get really annoyed if a compilation tool would decide the optimization if more important by default. Since this is visible, i'd suggest we allow optimizing, but keep original order by default.

[marcelloh]

Well, the code would not be written in .go files I just assumed, but in .goat files. Those can be in the desired order, while the transpiled .go files have the ideal order for the compiler. (and the json would of course return the ideal order)

[avivcarmis]

The problem is that reflection based code (like json) is executed in runtime and thus familiar only with the transpiled go files. Meaning that although the order of the goat file will be

A
B
C

In go it might be

B
A
C

for example, producing unexpected results. I'm fine with that and I agree that in most cases, developers would want automatic memory optimization. In edge cases they will be very surprised to discover them. If it was completely invisible then I totally agree. But since it is visible I think we should decide how to approach it. WDYT?

[marcelloh]

I think that nobody should trust the order of a json. It's a human readable data format with no specific ordering rules. So I'm all for using less memory. (But perhaps this can be a setting in the transpiler :-) )

[PaperPrototype]

@marcelloh I agree. Only problem is "if it's a side effect, it's a feature" and the fact is, go uses reflection for JSON