square / square/wire

Swift: clear a field's preserved unknown enum value from unknownFields when the field is mutated

Open
#3,710 0 comments 0 reactions 0 assignees View on GitHub

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 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.