FieldOptions

Value parameters

ctype

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.

debugRedact

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

deprecated

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.

features

Any features defined in the specific edition.

jstype

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. This option is an enum to permit additional types to be added, e.g. goog.math.Integer.

lazy

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. This is only a hint. Implementations are free to choose whether to use eager or lazy parsing regardless of the value of this option. However, setting this option true suggests that the protocol author believes that using lazy parsing on this field is worth the additional bookkeeping overhead typically needed to implement it. This option does not affect the public interface of any generated code; all method signatures remain the same. Furthermore, thread-safety of the interface is not affected by this option; const methods remain safe to call from multiple threads concurrently, while non-const methods continue to require exclusive access. Note that lazy message fields are still eagerly verified to check ill-formed wireformat or missing required fields. Calling IsInitialized() on the outer message would fail if the inner message has missing required fields. Failed verification would result in parsing failure (except when uninitialized messages are acceptable).

packed

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.

uninterpretedOption

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

unverifiedLazy

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

weak

For Google-internal migration only. Do not use.

Attributes

Companion

object

Graph

Reset zoomHide graphShow graph

Supertypes

trait ExtendableMessage[FieldOptions]

trait Updatable[FieldOptions]

trait GeneratedMessage

trait Serializable

trait Product

trait Equals

class Object

trait Matchable

class Any

Show all