FieldOptions

Information about the support window of a feature.

If set to RETENTION_SOURCE, the option will be omitted from the binary.

This indicates the types of entities that the field may apply to when used as an option. If it is unset, then the field may be freely used as an option on any kind of entity.

NOTE: ctype is deprecated. Use features.(pb.cpp).string_type instead. The ctype option instructs the C++ code generator to use a different representation of the field than it normally would. See the specific options below. This option is only implemented to support use of ctype=CORD and ctype=STRING (the default) on non-repeated fields of type "bytes" in the open source release. TODO: make ctype actually deprecated.

Indicate that the field value should not be printed out when using debug formats, e.g. when the field contains sensitive credentials.

Is this field deprecated? Depending on the target platform, this can emit Deprecated annotations for accessors, or it will be completely ignored; in the very least, this is a formalization for deprecating fields.

Any features defined in the specific edition. WARNING: This field should only be used by protobuf plugins or special cases like the proto compiler. Other uses are discouraged and developers should rely on the protoreflect APIs for their client language.

The jstype option determines the JavaScript type used for values of the field. The option is permitted only for 64 bit integral and fixed types (int64, uint64, sint64, fixed64, sfixed64). A field with jstype JS_STRING is represented as JavaScript string, which avoids loss of precision that can happen when a large value is converted to a floating point JavaScript. Specifying JS_NUMBER for the jstype causes the generated JavaScript code to use the JavaScript "number" type. The behavior of the default option JS_NORMAL is implementation dependent.

Should this field be parsed lazily? Lazy applies only to message-type fields. It means that when the outer message is initially parsed, the inner message's contents will not be parsed but instead stored in encoded form. The inner message will actually be parsed when it is first accessed.

The packed option can be enabled for repeated primitive fields to enable a more efficient representation on the wire. Rather than repeatedly writing the tag and type for each element, the entire array is encoded as a single length-delimited blob. In proto3, only explicit setting it to false will avoid using packed encoding. This option is prohibited in Editions, but the repeated_field_encoding feature can be used to control the behavior.

Returns the field-presence view for this com.google.protobuf.kotlin.FieldOptions instance.

The parser stores options it doesn't recognize here. See above.

unverified_lazy does no correctness checks on the byte stream. This should only be used where lazy with verification is prohibitive for performance reasons.

For Google-internal migration only. Do not use.

Copies the original message, including unknown fields.