+++
title = "Changes Announced on July 13, 2026"
linkTitle = "July 13, 2026"
toc_hide = "true"
description = "Changes announced for Protocol Buffers on July 13, 2026."
type = "docs"
+++

## Edition 2026 {#edition-2026}

We are planning to release Protobuf Editions to the open source project in 36.x
in Q3 2026.

These describe changes as we anticipate them being implemented, but due to the
flexible nature of software some of these changes may not land or may vary from
how they are described in this topic.

More documentation on Edition 2026 will be published in
[Feature Settings for Editions](/editions/features),
including the [migration guide](/support/migration).

## Changes to Existing Features {#changes-existing}

This section details any existing features whose edition_default will be changed
in Edition 2026.

### `enforce_naming_style`: `STYLE2026` {#enforce_naming_style}

The `enforce_naming_style` feature default will be updated to `STYLE2026` to
discourage common field-naming collisions.

Examples:

*   Within a message with a field named `x`, the following field names are
    banned:
    *   `has_x`
    *   `set_x`
    *   `get_x`
    *   `clear_x`
    *   `x_value`
*   Fields may not be named `descriptor`

### `default_symbol_visibility`: `STRICT` {#default_symbol_visibility}

[https://protobuf.dev/programming-guides/symbol_visibility/](https://protobuf.dev/programming-guides/symbol_visibility/)

The `default_symbol_visibility` feature default will be updated to `STRICT` to
encourage explicit use of `export` and `local` keywords and to, by default,
disallow exporting nested types.

This feature encourages the best-practices defined in
[1-1-1 Best Practice](/best-practices/1-1-1), which
advocates for narrowly defined .proto files to limit dependency bloat.

## New Features {#new-features}

This section details new features that will be introduced in Edition 2026.

### JSON option: custom JSON string for values {#json-custom-string}

Edition 2026 introduces a new JSON custom string option for enum values.

Prior to this release, we support custom keys using the `json_name` option. This
new option extends this behavior to values.

Renaming may be desirable for conflict avoidance, help in migrations, or to
satisfy external requirements.

Sample usage:

```protobuf
enum FOO {
   ...
   FOO_BAR = 5 [(pb.enumvalue.json).string = "custom_string_here"];
   ...
}
```

### C++ option: namespace {#cpp-namespace}

Edition 2026 introduces the new `namespace` C++ option as a custom option to
explicitly set the generated bindings namespace.

This allows C++ developers to specify binding language packaging independent of
the .proto package.

Use the new namespace C++ option as an example:

```protobuf
import option "google/protobuf/cpp_options.proto";

package clock.time;

option (pb.file.cpp).namespace = "clock_time";
```

### C++ options: C++ custom options moved out from descriptor.proto {#cpp-custom-options}

In Edition 2026, C++ language-specific options are moved from `descriptor.proto`
to separate custom option files.

To access these custom options for C++ in Edition 2026, import C++ language
custom options from using ```protobuf
import option "google/protobuf/cpp_features.proto";

option features.(pb.cpp).repeated_type = PROXY
```

The proxy type returned follows STL container naming conventions.

Some methods currently available on `RepeatedPtrField`/`RepeatedField` will not
be available via proxies, such as `AddAllocated`/`ReleaseLast`,
data/mutable_data, `pointer_begin`/`pointer_end`, and `GetArena`.

Sample usage:

```cpp
// Before:
google::protobuf::RepeatedPtrField<MyMessage>* rpf = message.mutable_repeated_message();
MyMessage* element1 = rpf->Add();
const MyMessage& element2 = rpf->Get(0);
MyMessage* element3 = rpf->Mutable(1);

// After:
google::protobuf::RepeatedFieldProxy<MyMessage> rpf = message.mutable_repeated_message();
MyMessage& element1 = rpf.emplace_back();
const MyMessage& element2 = rpf.get(0);
MyMessage& element2 = rpf[0];
```

`RepeatedFieldProxy` has no public constructors (aside from a shallow copy
constructor). Proxies can only be backed by repeated fields within a message. To
aid with migration, we have introduced a new type, `RepeatedFieldOrProxy`, which
is implicitly convertible from either a `RepeatedFieldProxy` or a legacy
`RepeatedPtrField`/`RepeatedField` reference. It otherwise has an identical
interface to `RepeatedFieldProxy`.

### C#: Add option and code generation for nullable reference types {#csharp-nullable}

Edition 2026 adds support for generating C# code that utilizes nullable
reference types.

This feature is opt-in and satisfies existing external user requests.

## Grammar Changes {#grammar-changes}

There is no new or removed grammar in Edition 2026.