You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tracked follow-up from #3708 (see the review discussion there).
Context
#3708 makes ProtoDecoder's .returnNil strategy preserve unrecognized singular enum values in the message's unknownFields, matching what repeated/map enum fields, generated Kotlin/Java, and proto2 semantics already do.
Preservation has a flip side, shared by all of those existing implementations: a client that mutates the unknown-valued enum field itself reencodes [known value][preserved unknown], and last-wins readers keep the unknown value — the client's edit is shadowed until it learns the new enum case. In Swift this is pinned by testEditedSingularEnumFieldReemitsPreservedUnknownValue.
Proposal
Generator-level clear-on-mutate: generated messages clear the corresponding unknownFields entry when a field is set — e.g. a didSet on the generated property, guarded so it does not fire during decode/init (where the decoder legitimately populates both the field and unknown fields). The generator knows each field's tag, so it can scope the clear precisely.
A generator-level shape is preferred over a runtime-only one (e.g. ProtoWriter skipping preserved values when the typed field is non-nil) because only the generator can distinguish "user mutated this field" from "decoder populated it", and because the same shadowing applies to repeated and map enum fields, where the writer can't safely tell a user-updated collection from a decoded one.
Notes
This is longstanding cross-platform behavior — generated Kotlin/Java and protobuf proto2 runtimes shadow the same way — so this would be an improvement over parity, not a regression fix. If pursued, it's worth deciding whether Kotlin/Java want the equivalent (builder/copy-level clearing).
A related singular-enum generator edge is disclosed in Preserve unknown singular enum values in unknown fields in Swift #3708: when the same singular enum tag occurs twice on the wire as [known, unknown], generated Swift assigns each decode result unconditionally, so the later unknown occurrence overwrites the known value with nil (generated Kotlin's catch skips the assignment). A fix there (skip assignment when the decode returns nil) is the same neighborhood of generated code and could ride along.
🤖 Filed by Logan's AI agent per the review discussion on #3708.
Tracked follow-up from #3708 (see the review discussion there).
Context
#3708 makes
ProtoDecoder's.returnNilstrategy preserve unrecognized singular enum values in the message'sunknownFields, matching what repeated/map enum fields, generated Kotlin/Java, and proto2 semantics already do.Preservation has a flip side, shared by all of those existing implementations: a client that mutates the unknown-valued enum field itself reencodes
[known value][preserved unknown], and last-wins readers keep the unknown value — the client's edit is shadowed until it learns the new enum case. In Swift this is pinned bytestEditedSingularEnumFieldReemitsPreservedUnknownValue.Proposal
Generator-level clear-on-mutate: generated messages clear the corresponding
unknownFieldsentry when a field is set — e.g. adidSeton the generated property, guarded so it does not fire during decode/init (where the decoder legitimately populates both the field and unknown fields). The generator knows each field's tag, so it can scope the clear precisely.A generator-level shape is preferred over a runtime-only one (e.g.
ProtoWriterskipping preserved values when the typed field is non-nil) because only the generator can distinguish "user mutated this field" from "decoder populated it", and because the same shadowing applies to repeated and map enum fields, where the writer can't safely tell a user-updated collection from a decoded one.Notes
[known, unknown], generated Swift assigns each decode result unconditionally, so the later unknown occurrence overwrites the known value withnil(generated Kotlin'scatchskips the assignment). A fix there (skip assignment when the decode returnsnil) is the same neighborhood of generated code and could ride along.🤖 Filed by Logan's AI agent per the review discussion on #3708.