An asymmetric field in a struct is considered required for the writer, but optional for the reader.

That's a nice idea... But I believe the design direction of proto buffers was to make everything `optional`, because `required` tends to bite you later when you realize it should actually be optional.

▲

bilkow 6 days ago | parent [-]

My understanding is that asymmetric fields provide a migration path in case that happens, as stated in the docs:

> Unlike optional fields, an asymmetric field can safely be promoted to required and vice versa.

> [...]

> Suppose we now want to remove a required field. It may be unsafe to delete the field directly, since then clients might stop setting it before servers can handle its absence. But we can demote it to asymmetric, which forces servers to consider it optional and handle its potential absence, even though clients are still required to set it. Once that change has been rolled out (at least to servers), we can confidently delete the field (or demote it to optional), as the servers no longer rely on it.

	▲	yencabulator 4 days ago \| parent \| next [-]
		> My understanding is that asymmetric fields provide a migration path in case that happens, as stated in the docs: If you can assume you can churn a generation of fresh data soonish, and never again read the old data. For RPC sure, but someone like Google has petabytes of stored protobufs, so they don't pretend they can upgrade all the writers.
	▲	sdenton4 4 days ago \| parent \| prev [-]
		....or we can just say that everything is optional always, and leave it to the servers instead of the protocol to handle irregularities.