問題タブ [objective-c-nullability]

nullability 関連の属性を読んで、Swift クライアントが使用できるように Objective-C コードを装飾します。これは間違いなく優れた機能であり、Swift の世界では API がよりクリーンになります。

しかし、私が疑問に思っているのは、純粋に Objective-C の世界で適切な使用法を強制するためにも使用できるかどうかです (つまり、Swift は全体像の一部ではありません)。

言い換えれば、ライブラリで公開されている関数の属性をマークして、nonnullそれを Objective-C から消費して渡すnilと、コンパイラは警告しますか?

これらの注釈について説明しているAppleのこの記事によると、「互換性」セクションで、注釈はABIに影響を与えないと具体的に述べているためです。次の行は、フレームワークを使用する既存のコードがそれに取り組んでいるときにどのように新しい警告を受け取るかについて述べていますが、それが Swift コードまたは Objective-C コードを意味するかどうかはわかりません.Swift コンパイラについて具体的に言及しています.

繰り返しになりますが、これらの属性は純粋な ObjC から ObjC への呼び出しに影響しますか?

Swift で使用するための一連のまたは ObjC コードを準備していますが、これにはもちろん nullability アノテーションが必要です。これらの nullability アノテーションは、定義ではなく、宣言サイトにのみ必要であることが私の理解です。つまり、宣言がヘッダー ファイルにあり、定義が am/mm ファイルにある場合、それらを後者に追加する必要はありません。

例えば...

フー.h:

ふー.mm:

現在、ObjC の経験が豊富な同僚の何人かは、両方の場所に行かなければならないと言っています。つまり、mm ファイルは実際にはこれでなければなりません...

ふー.mm:

理由を聞くと「合っている」とのこと。ただし、m/mm ファイルからそれらを削除すると、Swift はヘッダーのみを見ているため、それらがなくても問題なく Swift にインポートされているように見えます。

そうは言っても、テストしていない両方の場所でそれらを必要とする考慮すべきことが他にあるかどうかはわかりません。そのため、それが決定的であるとは言えません。

読みやすさと生産性

通常、後者が実際には何もしなくても、読みやすくするのに役立つ場合は、「両方の場所に配置してください」と言うだけで十分です。ただし、私たちの特定のケースでは、何万もの APIを更新する可能性があるため、多くの余分な作業を排除することは、誰にとっても大きなメリットになります。さらに、コード MOD の作成も容易になります。

これに関するAppleのドキュメントで見つけた最も近いものは、これらの2つの抜粋です（強調は私のものです）...

ただし、一般的なケースでは、これらの注釈を記述するためのはるかに優れた方法があります。メソッド宣言内では、型が単純なオブジェクトまたはブロック ポインターである限り、下線のない形式nullableを開き括弧の直後に使用できます。nonnull

と

アンダースコアのないフォームはアンダースコアのフォームよりも優れていますが、ヘッダーのすべてのタイプに適用する必要があります。その作業を容易にし、ヘッダーをより明確にするために、監査済みリージョンを使用する必要があります。

決定的ではありませんが。最初は、「宣言に固有の」「より良い方法」としてそれを呼び出している可能性がありますが、一般に注釈がそこにのみ行くとは言いません。後者も、アンダースコアなしのものはヘッダーで使用できると言っていますが、一般的にnull可能性アノテーションはヘッダーにのみ表示できるとは言っていません。監査された領域のみが表示されます。

とはいえ、Appleがこれを明確にする場所を知っている人はいますか?それとも、定義/実装でそれらをスキップしてもよいことを私たちに知らせる何か他のものを共有できますか?