Ah ... or is it the case that default values are not output? That seems to be what the current Java code & golang code is doing (?).

If that's the case, that gives me reasonable real-world compatibility between proto2 and proto3.

Unfortunately wrapper types change the wire format. The wire format will be the same as if these wrappers types are just normal messages. That said, changing primitive type to wrapper type isn't a wire compatible change. It should only be used in new proto3 syntax files that require field presence data.

Regarding encoding efficiency, the wrapper encoding will take one or two more bytes than the plain primitive fields. However, the wrapper types are only introduced for special cases, and are not encouraged to replace the optional primitive fields in proto2. We expect that most of the cases, field presence info is not needed. In proto3, optional primitives that equal to their defaults are not serialized, thus binary size should not be a concern.

Thanks for confirming that missing values are not output. I think that is an important thing to emphasize in discussions of the dropping of optional values. I think that is probably a step forward for usability, and I now much better understand why proto3 is dropping optional values (even though it is technically less powerful and maybe even less correct).

This doesn't solve my other complaint that hasX is gone, but that is probably me (ab)using protobuf for a purpose for which it wasn't intended.

I'm now much more excited about proto3!

@pherl have these primitive wrapper types landed in master somewhere yet? I can't seem to find them.

@zackangelo Yes. See https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto