From e45f5c717e02045aefd72e25e083cdb49d044098 Mon Sep 17 00:00:00 2001 From: Protobuf Team Bot Date: Tue, 3 Nov 2026 16:08:27 -0800 Subject: [PATCH] Internal change PiperOrigin-RevId: 1013367027 --- content/design-decisions/opaque-apis.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/design-decisions/opaque-apis.md b/content/design-decisions/opaque-apis.md index 46018179..0de8f521 100644 --- a/content/design-decisions/opaque-apis.md +++ b/content/design-decisions/opaque-apis.md @@ -83,9 +83,9 @@ because the presence bit is not reachable from the field expression itself. The typical representation ends up being a pointer per field — `*int32`, `*bool`, `java.lang.Integer` — which costs a machine word in the parent struct, a separate allocation, an extra indirection on every read, and garbage collector -pressure, all to carry one bit. Even in languages like Rust with Option, the -Open API precludes maintaining a dense hasbit bitmask over all of the fields, -and instead spreads out the option bit throughout the struct (including +pressure, all to carry one bit. Even in languages like Rust with `Option`, +the Open API precludes maintaining a dense hasbit bitmask over all of the +fields, and instead spreads out the option bit throughout the struct (including typically with a lot of wasting padding per field). Dense hasbits are not just cheaper to store; they make whole-message operations