|
| 1 | ++++ |
| 2 | +title = "Changes Announced on July 10, 2026" |
| 3 | +linkTitle = "July 10, 2026" |
| 4 | +toc_hide = "true" |
| 5 | +description = "Changes announced for Protocol Buffers on July 10, 2026." |
| 6 | +type = "docs" |
| 7 | ++++ |
| 8 | + |
| 9 | +## Edition 2026 {#edition-2026} |
| 10 | + |
| 11 | +We are planning to release Protobuf Editions to the open source project in 36.x |
| 12 | +in Q3 2026. |
| 13 | + |
| 14 | +These describe changes as we anticipate them being implemented, but due to the |
| 15 | +flexible nature of software some of these changes may not land or may vary from |
| 16 | +how they are described in this topic. |
| 17 | + |
| 18 | +More documentation on Edition 2026 will be published in |
| 19 | +[Feature Settings for Editions](/editions/features), |
| 20 | +including the [migration guide](/support/migration). |
| 21 | + |
| 22 | +## Changes to Existing Features {#changes-existing} |
| 23 | + |
| 24 | +This section details any existing features whose edition_default will be changed |
| 25 | +in Edition 2026. |
| 26 | + |
| 27 | +### `enforce_naming_style`: `STYLE2026` {#enforce_naming_style} |
| 28 | + |
| 29 | +The `enforce_naming_style` feature default will be updated to `STYLE2026` to |
| 30 | +discourage common field naming collisions. |
| 31 | + |
| 32 | +### `default_symbol_visibility`: `STRICT` {#default_symbol_visibility} |
| 33 | + |
| 34 | +[https://protobuf.dev/programming-guides/symbol_visibility/](https://protobuf.dev/programming-guides/symbol_visibility/) |
| 35 | + |
| 36 | +The `default_symbol_visibility` feature default will be updated to `STRICT` to |
| 37 | +encourage explicit use of `export` and `local` keywords and to, by default, |
| 38 | +disallow exporting nested types. |
| 39 | + |
| 40 | +This feature encourages the best-practices defined in |
| 41 | +[1-1-1 Best Practice](/best-practices/1-1-1), which |
| 42 | +advocates for narrowly defined .proto files to limit dependency bloat. |
| 43 | + |
| 44 | +## New Features {#new-features} |
| 45 | + |
| 46 | +This section details new features that will be introduced in Edition 2026. |
| 47 | + |
| 48 | +### JSON option: custom JSON string for values {#json-custom-string} |
| 49 | + |
| 50 | +Edition 2026 introduces a new JSON custom string option for enum values. |
| 51 | + |
| 52 | +Prior to this release, we support custom keys using the `json_name` option. This |
| 53 | +new option extends this behavior to values. |
| 54 | + |
| 55 | +Renaming may be desirable for conflict avoidance, help in migrations, or to |
| 56 | +satisfy external requirements. |
| 57 | + |
| 58 | +Sample usage: |
| 59 | + |
| 60 | +```protobuf |
| 61 | +enum FOO { |
| 62 | + ... |
| 63 | + FOO_BAR = 5 [(pb.enumvalue.json).string = "custom_string_here"]; |
| 64 | + ... |
| 65 | +} |
| 66 | +``` |
| 67 | + |
| 68 | +### C++ option: namespace {#cpp-namespace} |
| 69 | + |
| 70 | +Edition 2026 introduces the new `namespace` C++ option as a custom option to |
| 71 | +explicitly set the generated bindings namespace. |
| 72 | + |
| 73 | +This allows C++ developers to specify binding language packaging independent of |
| 74 | +the .proto package. |
| 75 | + |
| 76 | +Use the new namespace C++ option as an example: |
| 77 | + |
| 78 | +```protobuf |
| 79 | +import option "google/protobuf/cpp_options.proto"; |
| 80 | +
|
| 81 | +package clock.time; |
| 82 | +
|
| 83 | +option (pb.file.cpp).namespace = "clock_time"; |
| 84 | +``` |
| 85 | + |
| 86 | +### C++ options: C++ custom options moved out from descriptor.proto {#cpp-custom-options} |
| 87 | + |
| 88 | +In Edition 2026, C++ language-specific options are moved from `descriptor.proto` |
| 89 | +to separate custom option files. |
| 90 | + |
| 91 | +To access these custom options for C++ in Edition 2026, import C++ language |
| 92 | +custom options from using ```protobuf |
| 93 | +import option "google/protobuf/cpp_features.proto"; |
| 94 | + |
| 95 | +option features.(pb.cpp).repeated_type = PROXY |
| 96 | +``` |
| 97 | +
|
| 98 | +The proxy type returned follows STL container naming conventions. |
| 99 | +
|
| 100 | +Some methods currently available on `RepeatedPtrField`/`RepeatedField` will not |
| 101 | +be available via proxies, such as `AddAllocated`/`ReleaseLast`, |
| 102 | +data/mutable_data, `pointer_begin`/`pointer_end`, and `GetArena`. |
| 103 | +
|
| 104 | +Sample usage: |
| 105 | +
|
| 106 | +```cpp |
| 107 | +// Before: |
| 108 | +google::protobuf::RepeatedPtrField<MyMessage>* rpf = message.mutable_repeated_message(); |
| 109 | +MyMessage* element1 = rpf->Add(); |
| 110 | +const MyMessage& element2 = rpf->Get(0); |
| 111 | +MyMessage* element3 = rpf->Mutable(1); |
| 112 | +
|
| 113 | +// After: |
| 114 | +google::protobuf::RepeatedFieldProxy<MyMessage> rpf = message.mutable_repeated_message(); |
| 115 | +MyMessage& element1 = rpf.emplace_back(); |
| 116 | +const MyMessage& element2 = rpf.get(0); |
| 117 | +MyMessage& element2 = rpf[0]; |
| 118 | +``` |
| 119 | + |
| 120 | +`RepeatedFieldProxy` has no public constructors (aside from a shallow copy |
| 121 | +constructor). Proxies can only be backed by repeated fields within a message. To |
| 122 | +aid with migration, we have introduced a new type, `RepeatedFieldOrProxy`, which |
| 123 | +is implicitly convertible from either a `RepeatedFieldProxy` or a legacy |
| 124 | +`RepeatedPtrField`/`RepeatedField` reference. It otherwise has an identical |
| 125 | +interface to `RepeatedFieldProxy`. |
| 126 | + |
| 127 | +### C#: Add option and code generation for nullable reference types {#csharp-nullable} |
| 128 | + |
| 129 | +Edition 2026 adds support for generating C# code that utilizes nullable |
| 130 | +reference types. |
| 131 | + |
| 132 | +This feature is opt-in and satisfies existing external user requests. |
| 133 | + |
| 134 | +## Grammar Changes {#grammar-changes} |
| 135 | + |
| 136 | +There is no new or removed grammar in Edition 2026. |
0 commit comments