Rust Types and Required Messages

As requested by [ @esrauchg ]( https://github.com/esrauchg ), moving the conversation here:

https://github.com/tokio-rs/prost/issues/1031#issuecomment-2932003751 .

Although this originated in a `prost` discussion, the underlying issue concerns

how the official protobuf toolchain treats field presence. The intent here is to

clarify the expected stance and behavior of the generator.

**What language does this apply to?**

Primarily **Rust** , but also interested in **Go** and **TypeScript** as they

relate to protobuf code generation.

**Describe the problem you are trying to solve.**

The generated types are structurally imprecise: **all fields are wrapped in `Option<T>` ** ,

even those marked as `required` (explicitly or implicitly) in the proto

definition.

This leads to:

- Verbose boilerplate ( `Some(...)` wrappers)

- Increased cognitive overhead

- Risk of runtime errors when unwrapping values that should be guaranteed

```rust

fn calculate_minimum_bid_increment (cmd : & StartAuctionRun ) -> Result < MoneyAmount , Error > {

match & cmd . minimum_bid_increment_policy {

Some (policy) => match & policy . policy {

Some ( minimum_bid_increment_policy :: Policy :: Fixed (fixed_policy)) => {

//...

}

// ...

// NOTE: this should never happen, it is required

None => Err ( Error :: MinimumBidIncrementPolicyRequired ),

},

// NOTE: this should never happen, it is required

None => Err ( Error :: MinimumBidIncrementPolicyRequired ),

}

}

```

Despite the domain clearly requiring this field, the type system does not

enforce it. Structurally speaking.

We're using protobuf as the canonical schema for all:

- Commands

- Events

- Aggregate Snapshot

That applies across multiple language runtimes (via WASM modules) and is

critical for:

- Schema evolution and change detection

- Consistent interop across services

- Serialization correctness

- Avoiding runtime reflection or manual encoders/decoders

We treat protobuf-generated types as the source of truth and only validate

`commands` post-deserialization (or via protovalidate extension).

Here is the existing callbacks (thus far):

```rust

pub type InitialState < State > = fn () -> State ;

pub type IsTerminal < State > = fn (state : State ) -> bool ;

pub type Decide < State , Command , Event , Error > =

fn (state : & State , command : Command ) -> Result < Decision < State , Command , Event , Error >, Error >;

pub type Evolve < State , Event > = fn (state : & State , event : Event ) -> State ;

pub type GetStreamId < Command > = fn ( Command ) -> String ;

pub type IsOrigin < Event > = fn ( Event ) -> bool ;

pub type GetEventID < Event > = fn ( Event ) -> String ;

```

**Describe the solution you'd like**

The code generator should respect the `required` field modifier in `.proto`

definitions, emitting non-optional Rust fields where appropriate.

That would:

- Better align with schema intent

- Eliminate unnecessary `Option<T>` wrappers

- Improve safety and ergonomics

**Describe alternatives you've considered**

Creating application-level copies of protobuf types, but such types

have very little value in our context. The distintion between application

and serialization matters better little to us, especially when protobuffer

files can not break change.

**Additional context**

- https://github.com/tokio-rs/prost/pull/1286

- https://github.com/tokio-rs/prost/issues/1031

Can you clarify a bit more what it is you are trying to achieve, and if there are any official implementations where Option/nullability is a pain point?

If I'm following collectly, on all official implementations you should be able to get the behavior you're describing by just declaring the child messages and just don't check their has-bits. As far as the observable behavior is concerned all of the submessages being eagerly allocated or lazily allocated should be an implementation detail.

This does make perfect sense in general: if required was newly created in 2025 it maybe could try to have semantics of always having Builders, being able to parsePartial into Builders. Note that not many of the official implementations of Protobuf do not use builder pattern though, so anything like that would be very difficult to retrofit.

But the context is more that the idea of "blanket enforcement of presence of a field at parse time" is considered a misfeature (as discussed in the "Required is Strongly Deprecated" section  here ). Under the expected usecase patterns of Protobuf, its considered a big footgun since many people believe they have a field that is obviously always strictly required, but actually a few years later they will want to replace it with something different, and hard enforcement at parse time makes that evolution almost impossible.

Zooming out a bit: for the usecase you're describing, for the official Google supported implementations, I think just doing the normal / natural thing should be able to achieve the effective behavior you're thinking about. Make a normal message, make it have normal message-typed fields, treat it as normal child structs which are just "always there". Treat the maybe-lazy-allocation of those inner structs as an implementation detail, and treat the has-bit tracking as an implementation detail. If the default-initialized child struct isn't a valid value, check in your application code against that condition, rather than checking against the hassers (it would practically never matter for "this is a valid value of the child" if the child message field was set but in turn none of the fields on it were set anyway).

With Prost specifically, it may be harder to achieve that pattern naturally since all of the message-typed fields are typed as Option<>, but thats the nature of it and there's some tradeoffs Prost makes in turn for other ergonomic benefits. The V4 official Rust impl is in beta right now, it is an opaque api instead of open structs and so doesn't have the same implication, but it does end up being a design choice that will come with a number of other tradeoffs (some of which are already detailed in our beta documentation here ).

Thanks!