proto3 no-longer generates pointers to fields

[ralfthewise]

In proto2 fields were generated as pointers, which allowed us to check if a field was specified or not. This no longer seems to be the case. For example:

proto2:

syntax = "proto2";

message Foo {
  required int32 ID = 1;
  optional int32 SortOrder = 2;
}

gives

type Foo struct {
    ID               *int32 `protobuf:"varint,1,req" json:"ID,omitempty"`
    SortOrder        *int32 `protobuf:"varint,2,opt" json:"SortOrder,omitempty"`
    XXX_unrecognized []byte `json:"-"`
}

proto3:

syntax = "proto3";

message Foo {
  int32 ID = 1;
  optional int32 SortOrder = 2;
}

gives

type Foo struct {
    ID        int32 `protobuf:"varint,1,opt" json:"ID,omitempty"`
    SortOrder int32 `protobuf:"varint,2,opt" json:"SortOrder,omitempty"`
}

Is this the expected behavior, and if so how are we supposed to differentiate a client making a call with SortOrder = 0 vs one making a call and not specifying the SortOrder?

[dsymonds]

That's working as intended, and a deliberate choice for proto3. You simply aren't supposed to differentiate fields explicitly set to their zero value from fields not touched at all.

[myitcv]

@dsymonds - unless I'm missing something, the README still refers to the generation of pointer fields. Is there somewhere with updated documentation for proto3?

[myitcv]

This seems the most relevant.

[dsymonds]

I'll update the README to mention the difference.

[myitcv]

@dsymonds - thanks

[Sahasrara]

Documentation still says "Non-repeated fields are pointers to the values; nil means unset. That is, optional or required field int32 f becomes F *int32."

It it possible to specify that pointers be used. It really saves a lot of pain.

[dsnet]

The documentation could be clearer, but below the bullet point list it says:

When the .proto file specifies syntax="proto3", there are some differences:
    Non-repeated fields of non-message type are values instead of pointers.

[wikiwong]

I would love to hear an explanation of the design decision to no longer allow primitives to be expressed as pointers. There are many real world cases in which (for let's say, an int64) a 0 does not mean unset.

[dsnet]

I would love to hear an explanation of the design decision to no longer allow primitives to be expressed as pointers. There are many real world cases in which (for let's say, an int64) a 0 does not mean unset.

The Go team is not responsible for the protobuf language design. As such, we are unable to answer questions about motivation. Please redirect questions towards protocolbuffers/protobuf#1606