view: opt-in ViewEncode for serializing from borrowed fields

[rpb-ant]

view: ViewEncode — serialize from borrowed fields

log_record build+encode from &str source: 1.35 µs → 227 ns (5.96×). Serialize-only at parity with owned Message::encode (±5%).

Why

Encoding currently requires building an owned message — cloning every string and map entry just to pass &self to Message::encode(), then dropping the struct. When the source data is already in-memory &strs (RPC handlers serializing from app state), that's ~19 allocs/message for a typical string-heavy payload. Views already have &'a str fields and pub constructors; this adds the encode side.

Change

ViewEncode<'a>: MessageView<'a> sub-trait with the same two-pass compute_size/write_to model as Message. Generated *View<'a> types implement it whenever views are generated (generate_views(true), the default).

The codegen reuses the existing per-field encode-stmt builders unchanged — they already emit &self.field-relative code that takes &str/&[u8], so they apply to view fields as-is. Oneof same: arm builders are duck-typed; pointing them at the view-side enum is the only delta. MessageView itself is unchanged.

Compatibility — 0.4.0

The trait surface is additive, but every generated view struct gains a __buffa_cached_size field — public-shape change for code that constructs views without ..Default::default(). Folded into 0.4.0 alongside the existing Any.value: Bytes break in Unreleased. Uncalled .text cost is negligible (~12 B/message in release, no LTO; the linker dedups identical cached_size bodies and write_to is generic so it monomorphizes only at call sites).

Testing

Every view-generating buffa-test proto exercises the encode path (proto3, proto2 groups/closed-enums, nested oneofs, WKT, utf8_validation=NONE, use_bytes_type, preserve_unknown_fields=false, edge_cases) — compile-time coverage for the duck-type-reuse claim across syntaxes. 9 view-encode round-trip / construct-from-borrows tests. Conformance 6× PASSED, 0 unexpected.

Companion

For connectrpc handlers, connect-rust needs a way to return pre-encoded bytes (PreEncoded newtype). Companion PR linked once open. This change is independently useful for any non-connectrpc encode path.

Follow-ups (not here)

• MessageFieldView boxes the inner view (recursive types) — one alloc per nested-message field; non-boxed variant for non-recursive fields would close the gap for tree-shaped messages.
• via-view-encode conformance mode (decode_view → encode_view).

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[rpb-ant]

I have read the CLA Document and I hereby sign the CLA

[rpb-ant]

Why ViewEncode is always-on (no view_encode flag)

An earlier draft of this PR gated ViewEncode behind Config::view_encode(false) (opt-in, mirroring generate_text). Review pushed back on that, and after measuring we dropped the flag. Here's the reasoning.

Options considered:

	description	downside
A	keep view_encode flag, flip default to true	one more config knob (#9); the WKT struct-shape break lands in 0.4.0 regardless of the flag, so it doesn't actually protect against the break
B	drop the flag; tie ViewEncode to generate_views	the (narrow) audience that wants zero-copy decode but never encode-from-borrows pays for unused codegen
C	keep flag, default false (original draft)	common case requires config; WKT break still lands; generate_text analogy is weak (that flag exists because it gates a runtime feature dep — ViewEncode has none)

Why B: the cost B imposes turns out to be negligible. Measured on buffa-test (82 messages, release build, no LTO, ViewEncode generated but never called):

	.text
view_encode off	2,724,340 B
view_encode on, uncalled	2,725,288 B
Δ	+948 B (~12 B/message)

write_to(&mut impl BufMut) is generic — zero .text unless monomorphized at a call site. cached_size impls are 4 bytes each and the linker deduplicates identical bodies (nm shows e.g. Int32ValueView::cached_size and FloatValueView::cached_size at the same address). compute_size is the only per-message unique code.

For a hypothetical 1000-message embedded schema without LTO that's ~12 KB; with LTO (standard for size-constrained builds) it's zero. The escape hatch for anyone who genuinely can't afford it is the existing generate_views(false).

So: one fewer config knob, no meaningful cost, and the __buffa_cached_size struct-shape break is already in 0.4.0 via WKTs anyway.

[rpb-ant]

Built a standalone echo bench to test whether view-decode pays off without view-encode: 906-byte string-heavy request (4 strings, 8 tags, 10-entry label map), measuring the full bytes-in → decode → build response → encode → bytes-out pipeline. Baseline uses move semantics (most charitable to owned).

Path	latency	RPS/core	vs baseline
owned-decode → owned-encode	1.433 µs	698k	1.00×
view-decode → owned-encode	1.223 µs	818k	1.17×
owned-decode → view-encode	1.397 µs	716k	1.03×
view-decode → view-encode	655 ns	1.53M	2.19×

View-decode alone: +17%. View-encode alone: +3%. Both: +119% — far more than the sum, because only view→view eliminates the string-alloc pass entirely (the &'a str from the request wire buffer flows straight to the response buffer with zero intermediate String). Either half alone still does one full alloc pass. So ViewEncode isn't a standalone win — it's the piece that unlocks the view-decode investment for echo-shaped handlers.