Is this message deprecated?
Depending on the target platform, this can emit Deprecated annotations
for the message, or it will be completely ignored; in the very least,
this is a formalization for deprecating messages.
Implementations may choose not to generate the map_entry=true message, but
use a native map in the target language to hold the keys and values.
The reflection APIs in such implementations still need to work as
if the field is a repeated message field.
NOTE: Do not set the option in .proto files. Always use the maps syntax
instead. The option should only be implicitly set by the proto compiler
parser.
Set true to use the old proto1 MessageSet wire format for extensions.
This is provided for backwards-compatibility with the MessageSet wire
format. You should not use this for any other reason: It's less
efficient, has fewer features, and is more complicated.
The message must be defined exactly as follows:
message Foo {
option message_set_wire_format = true;
extensions 4 to max;
}
Note that the message cannot have any defined fields; MessageSets only
have extensions.
All extensions of your type must be singular messages; e.g. they cannot
be int32s, enums, or repeated messages.
Because this is an option, the above two restrictions are not enforced by
the protocol compiler.
public bool NoStandardDescriptorAccessor { get; set; }
Disables the generation of the standard "descriptor()" accessor, which can
conflict with a field of the same name. This is meant to make migration
from proto1 easier; new code should avoid fields named "descriptor".
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-01-28 UTC."],[],[]]