[dmi]

> If all you want to send is an array of integers, why should you have to put it into a struct first?

If you're sure that's all you'll ever have to do, then sure. But unless you're 100% certain that the protocol will never evolve further, having a more complex structure allows it to change in a gradual way.

[lsaferite]

It was clear, from the post, that they were saying, "If all I need is a simple array, why should I be required to wrap it in a struct?" The whole point (from the post) being that protobuf required structs but gob allowed simpler types _in addition_ to structs.

[orf]

all I need _right now_ is a simple array

Nobody knows the future, and preparing for the future is a huge part of software engineering. Sending top-level arrays instead of sending them inside a struct is never the right way.

[lsaferite]

> Sending top-level arrays instead of sending them inside a struct is never the right way.

While I understand the sentiment, I 100% disagree on the 'never' qualifier.

[orf]

Depending on if the format you use is self-describing or not, it’s possible “sending a plain array” and “sending a struct with 1 field that is an array” could have the same format on the wire.

If it is self describing, the overhead could be very very minimal.

So, why would you want to send a plain array without wrapping it in a struct?

[Thorrez]

dmi knows that. dmi was saying that even if the encoding scheme allows encoding simpler types, it's often not smart to use that functionality, because you won't be able to evolve the format in the future. If you encode a message instead of a simple type, you'll be able to evolve it later as you add more features to your program.

Note that even protobufs, which doesn't allow encoding simple types at the top level, still has this debate when deciding whether to encode an array of simple types (inside a struct) or an array of structs (inside a struct). And Google's guidance is to use an array of structs if more data might be needed in the future:

>However, if additional data is likely to be needed in the future, repeated fields should use a message instead of a scalar proactively, to avoid parallel repeated fields.

https://google.aip.dev/144

>// Good: A separate message that can grow to include more fields

https://protobuf.dev/programming-guides/api/#order-independe...