donmendelson
commented
2 years ago The inheritance of attributes from <field> and the members of a composite type.
Nevertheless, v1.0 specification states that "presence mismatch" is an error. If the attribute is specified on both a field and the encoding that it references, the values must be identical.
Current design feels like field was not intended to introduce new types, only reuse them. Agree.
Because of that I think that the right way is to allow field to have presence only for built-in types. "built-in" is not a term used by the specification. Perhaps you mean primitives.
OleksandrKvl
This is a generalization of unanswered #153. Documentation says that
<field>inherits presence from its type but it doesn't say if or when it can be overridden. I believe documentation is a bit wrong because it says that the default value forpresenceisrequired, however looks like this can be true only if a field is of a built-in type, in all other cases presence by default is inherited from a custom type.Here's a couple of tricky cases:
const, field using it is non-const, is it valid at all?presenceat all, they are alwaysrequired, hencefield.presencedoesn't make much sense for them.optional, field isrequired, this has no implementation problems since one can just ignorenullValuebut does it make any sense?required, field isoptional, what should benullValuefor such a field? Btw, this means that field creates new type which is against field's nature (see below).Current design feels like
fieldwas not intended to introduce new types, only reuse them. Because of that I think that the right way is to allow field to havepresenceonly for built-in types. For all other cases it should be inherited (and can't be overridden) from type itself.Please clarify how it should work.