Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#3,710 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
kotlin, swift
領域
tooling

調査の方向性

issue に記載されている generator レベルの generated property の動作から始め、#3708 を確認してから、testEditedSingularEnumFieldReemitsPreservedUnknownValue を実行します。ProtoDecoder の初期化と generated assignment path を追跡し、クリアが decode/init ではなくユーザーによる変更に対してのみ行われるようにします。完了条件は、編集された singular、repeated、map の enum フィールドが保持していた unknown value を再出力しなくなり、decode 中は引き続きそれらが保持されることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Kotlin
スター
4.4k
フォーク
633
平均マージ
1日 16時間
マージ済み PR（30日）
10

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

square/wire のほかの issue

square/wire の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。