Is is possible to force Wire to generate non-null fields by default?

[erawhctim]

I'm new to protobuf & Wire, so I may be misunderstanding the intended use of both.

Currently I'm confused why my Wire-generated Kotlin models have nullable fields even though the protobuf fields aren't marked as optional.

In the docs, I see that Wire is pretty explicit about nullability:

The nullability of each field’s type depends on its label: required, repeated and map fields get non-nullable types, whereas optional fields are of nullable types.

With the exception of required fields, each field has a default value:
null for optional fields,

I think the root cause in my case is that these fields don't use the required keyword.

I've since learned that required was removed from proto3; based on that, my assumption is that every field not marked as optional in the protobuf model would be non-null in the Kotlin model (but that doesn't seem to match Wire's default behavior). Why is that?

Is this an incorrect way to indicate nullability/presence in a protobuf model? (and if so, what's the alternative recommendation)
Is there a way to configure Wire in a different way to work around this, possibly with a custom SchemaHandler?

[oldergod]

What optional or required define is what we internally call the label. While they are both explicit, the absence of label in proto3 is tricky. If there are no label, the field defaults to its identity value. For numbers, it's gonna be 0; for strings, it's gonna be ""; for messages, it's gonna be null. This is why message-type fields without a label will be generated as val field: Message? = null in Kotlin. You can deduce now why they added the optional label back in proto3: because not everything is optional in proto3.
There are no workaround in proto3 to get non-nullable message-type fields as far as I know.

Here are a few slides from a talk I did recently.

[erawhctim]

Thanks for the detailed response! I appreciate the snippets, as well as all of your hard work on Wire - it's a fantastic plugin.

There are no workaround in proto3 to get non-nullable message-type fields as far as I know.

Is there a way to work around this in Wire specifically? Say, if we wanted to configure it to assume that all Message-type fields are non-null, is that possible today?

If not, how do you and your team(s) typically work around this? We're exploring gRPC and protobuf for newer APIs, and I think a lot of us are finding this limitation in proto3 surprising (having previously assumed that optionality/presence could be properly represented in a protobuf model and built into a generated model accordingly).

We can always build checks/assumptions into our network parsing layer to force certain fields as non-null, of course, but hand-checking the optionality of each field on a response seems a bit backwards/negated compared to the idea(s) behind protobuf & code generation.

[oldergod]

We do not use proto3 that much for .proto files. The whole schema is 99% proto2 messages with a few proto3 types such as Timestamp and Duration used in some places. In this scenario, you could use required.
Otherwise, you could create your own option with your own generation handler but that seems like an overkill.

Even though we're using proto2, almost all fields are set to optional and we sync among clients/servers to know when someone can field!! in their code or not. This has been a recurring topic in-house but unless you're super sure that the field is relevant till the end of time, it can fireback to set fields to required.

[erawhctim]

Gotcha; makes sense! Thanks again, I appreciate your help