Swift: clear a field's preserved unknown enum value from unknownFields when the field is mutated
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 4.4k
- Forks
- 627
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 20
Description
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 #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 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the generator-level generated property behavior described in the issue and review #3708, then run testEditedSingularEnumFieldReemitsPreservedUnknownValue. Trace ProtoDecoder initialization and the generated assignment path so clearing is limited to user mutation, not decode/init. Done means edited singular, repeated, and map enum fields no longer reemit their preserved unknown values while decoding still preserves them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin, swift
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100