title: how do has_field() methods relate to default values in protobuf?
body: <p>I'm trying to determine the relationship between <strong>default values</strong> and the <strong>has_foo()</strong> methods that are declared in various programmatic interfaces.  In particular, I'm trying to determine under what circumstances (if any) you can "tell the difference" between a field explicitly set to the default value, and an unset value.  </p>
  
  <ol>
  <li><p>If I explicitly set a field (e.g. "Bar.foo") to its default value (e.g., zero), then is Bar::has_foo() guaranteed return true for that data structure?  (This appears to be true for the C++ generated code, from a quick inspection, but that doesn't mean it's guaranteed.)  If this is true, then it's possible to distinguish between an explicitly set default value and an unset <em>prior to serialization</em>.</p></li>
  <li><p>If I explicitly set a field to its default value (e.g., zero), and then serialize that object and send it over the wire, will the value be sent or not?  If it is not, then clearly any code that receives this object can't distinguish between an explicitly set default value and an unset value.  I.e., it won't be possible to distinguish these two cases <em>after serialization</em> -- Bar::has_foo() will return false in both cases.</p></li>
  </ol>
  
  <p>If it's not possible to tell the difference, what is the recommended technique for encoding a protobuf field if I want to encode a "nullable" optional value?  A couple options come to mind, but neither seem great: (a) add an extra boolean field that records whether the field is set or not, or (b) use a "repeated" field even though I semantically want an optional field -- this way I can tell the difference between no value (length-zero list) or a set value (length-one list).</p>