On Thu, May 30, 2019 at 10:50 AM prasanth somasundar <[email protected]> wrote:
> Pointer field defaults: Field defaults in general are not features I feel > super great about. Not that I’ve thought about this in horribly great > depth, but they seem to be very problematic if they are ever updated – your > binaries will read the same bytes as two different structs. I always > assumed that’s why they were removed from proto3. They also don’t seem * > *that** useful as you can handle this on the application layer > sufficiently well. I’m curious if others think differently and feel > strongly about their inclusion. > Default values for pointers are almost never needed, mainly because it usually makes more sense for the app to check for null and implement a fallback explicitly, rather than try to construct a default that represents the right fallback. For primitive fields, I use defaults all the time. The purpose of a default is to express how to handle messages from senders who are unaware of the field, e.g. because they were written before the field existed. I find quite often that when I introduce, say, a new boolean field, I set the default to `true`, because it controls a thing that was historically "on" but should now be possible to turn "off". (You could alternatively phrase the field name as a negative, like "disableFoo", but that leads to code containing double-negatives which are really hard to read.) Proto3's motivation for removing defaults, as I understand it, is that the designers of Go very much wanted for Protobufs to be represented as raw structs. Go does not have a concept of constructors for raw structs; they are simply zero-initialized. Instead of improving their language, they asked for changes to Protobuf. This was also the motivation to get rid of "unknown field retention", which stores unknown fields seen on the wire off to the side so that if the message is serialized again, they can be included. And it was also the motivation to get rid of the ability to distinguish "set to default value" from "unset". I've beet told that despite all this effort, it was eventually concluded that raw Go structs still were not a good representation for protobufs... -Kenton -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQ%3DAzKGLToFzXhrny6mOXGAhC9VwpSxYyQKnmt5B4ZFgjg%40mail.gmail.com.
