Not only `required` documents the intention, it helps us writing less
validation code.

For example, look at `Entity` fields and motivation behind making them
required [1]. Before making this change we were discussing the alternative
`optional` + extra validation, but decided to go the `required` way because
it is *less* code.

I understand arguments against `required` (though downgrade to `optional`
is possible with our support policy). We will have to go through the change
`required` -> `optional` anyway—and write a bunch of validation code—if we
decide to move to proto3.

I agree with the suggestion to be mindful about adding new required fields.
However, in certain cases I still see value from using them and would
exploit this possibility while we are still on proto2.

[1]
https://github.com/apache/mesos/blob/30d703fe81eacf64e9d84503074579cf5667bea1/include/mesos/authorizer/acls.proto

On Thu, Jun 23, 2016 at 10:17 PM, Joris Van Remoortere <[email protected]>
wrote:

> I think it would be great to comment in place e.g. `/* required */ optional
> <field>`.
> It's difficult enough as is to extract the semantics out of the current
> Protos. The required helped document which fields were actually required.
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Thu, Jun 23, 2016 at 2:40 AM, Jie Yu <[email protected]> wrote:
>
> > +1
> >
> > Proto3 killed 'required' keyword.
> >
> > On Wed, Jun 22, 2016 at 5:15 PM, Jay JN Guo <[email protected]>
> wrote:
> >
> > >
> > >
> > > Hi,
> > >
> > > I find marking protobuf field as 'required' sometimes causing trouble:
> > > serializing a message without filling up required field generates
> errors
> > > and this is hard to change due to backwards compatibility. And this
> > message
> > > type is actually discouraged by protobuf:
> > >
> > >
> >
> https://developers.google.com/protocol-buffers/docs/proto#specifying-field-rules
> > >
> > > So is there a particular reason we are doing it? I would suggest to use
> > > optional and repeated onwards if possible and add more verification
> logic
> > > instead.
> > >
> > > /Jay
> > >
> >
>

Reply via email to