Decide field-addition / struct-literal evolution policy for generated structs (non_exhaustive, builders, or documented rule)

[iainmcgin]

Generated view structs (FooView<'a>, FooLazyView<'a>) and owned message structs are emitted as plain pub struct with all-pub fields. Any addition of a field is therefore a compile-breaking change for downstream code that constructs these types with an exhaustive struct literal (no ..Default::default()) or destructures them exhaustively.

Two recent changes make this more than a theoretical concern:

• views: additive FooLazyView family for opt-in lazy decoding #188 added __buffa_unknown_fields handling and the lazy view family.
• views: track proto2 required-field presence on MessageView #200 adds hidden #[doc(hidden)] pub __buffa_required_seen_N: u64 bookkeeping words to views of messages with proto2/editions required fields. A consumer who built such a view with an exhaustive literal on the previous release fails to compile after upgrading, even though their .proto did not change.

The same property applies to ordinary schema evolution: adding a field to a message in the .proto breaks exhaustive literals of the owned struct, which is conventional for protobuf codegen (prost behaves the same way), but we have never stated a policy.

Options

1. #[non_exhaustive] on generated view structs. Makes the rule compiler-enforced, but prohibits struct-literal construction outside the generated crate entirely — including Foo { x, ..Default::default() } — which breaks the legitimate "hand-build a view to encode it" use-case and every existing test that constructs views literally.
2. Document the policy (views and owned messages are constructed via decode/Default/setters; exhaustive literals are not covered by semver) without changing codegen.
3. Generated constructors/builders for views, paired with either option 1 or 2, so there is an ergonomic non-literal construction path before any enforcement lands.

Option 1 alone is probably too blunt for the current API; some combination of 2 now and 3 later seems more plausible. Worth deciding before the 0.8.0 line stabilises, since whichever rule we pick shapes what counts as a breaking change for every release after it.

[rsd-darshan]

Option 2 + path to Option 3 seems like the right balance here.

Now (0.8.0): Document the policy clearly — add a note to the struct doc comments. This is honest, aligns with prost's convention, and costs almost nothing.

Later (post-0.8.0): If builder ergonomics become a pain point, Option 3 gives users a stable construction path that never breaks. But that's a follow-up based on actual usage patterns, not preemptive design.

Option 1 alone cuts off too much, and without builders in place first, it leaves users with no good way to construct views.

This path keeps Phase 1 simple and leaves room to add convenience later if needed.