Marking all fields as optional in proto3

[Jeppe Fihl-Pearson]

Hi

Is there any big downside to marking all fields optional in proto3 besides the slightly larger resulting wire format?

In our case, we will use Protobuf/gRPC for server-to-server communication, where a bit of network overhead doesn't matter.

Knowing whether a field has been populated seems like a nice benefit of marking fields optional, and it also appears to be the default for the "2023 edition” version.

I'm wondering if marking all fields as optional would be considered an anti-pattern and if this shouldn't be necessary if the messages are better structured.

Thanks

Jeppe

[Marc Gravell]

(to be clear: I'm just a lurker here - this is just an opinion, not an official answer of any kind)

IMO that's absolutely fine; it isn't even necessarily any larger; in many cases it'll be exactly the same size - it'll only be larger when fields are *explicitly* assigned zero/false/etc, and the delta is minimal (commonly +2 bytes per such value, depending on the field number)

Marc

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/protobuf/c012cb4e-1057-4c79-9ca4-3454afd1e3ffn%40googlegroups.com.

--

Regards,

Marc

[Em Rauch]

If you are using Proto3 and find the has-bit even a little bit useful, you should go ahead and use optional. If you're using Proto3 and don't want to use it, obviously that's great too.

The protobuf team may publish some info about the history of proto2 > proto3 > Editions decisions to comment on this more officially, but broadly what happened is Proto3 was designed with the idea that some implementations could be a cleaner or more efficient API if they didn't need to try to maintain has-bit, which did happen notably the Go Proto API (before the refreshed Opaque API). But over time it became clear that most language implementations didn't get meaningful API or performance wins by losing the has-bit, and having the hassers ready and available for the cases where they were needed was useful to applications, so going forward we expect fields having presence is the best default choice.

To view this discussion visit https://groups.google.com/d/msgid/protobuf/CAF95VAye%2BMW2tY2rALOLHbTwJECqVta5naKJLjEFHdmtNx0_fQ%40mail.gmail.com.