Swift コンパイラの警告を無視できないようにする

Swift / iOS 界隈では Optional(2018) 年 が話題ですが、子育てエンジニアになったばかり の mono  さんが以前このようにツイートしていました。

これは Optional(2018) 年対策のひとつとしてアリですね。

@koher‏ さんが昨日 Qiita で記述されたとおり、デフォルトではコンパイル時の警告（⚠️）を無視できます。

マジレスすると『Optional(2018)年』を恐れる必要はない - Qiita

コンパイル時の警告はエラーではないので、無視して実行することはできます。しかし、警告は常に対処して発生しないようにしておくべきものです。仮に都度対処するのが大変でも、リリース前には対処しておくべきでしょう。やむを得ず残ってしまう警告があるとしても、問題のある警告が残ってないかリリース前にチェックするのは品質を担保するために必須の作業です。これはもはや null 安全とは関係のない一般的な開発の話です。

そして mono  さんがツイートされた SWIFT_TREAT_WARNING_AS_ERRORS = YES は、警告ではなくエラー（🚨）にして無視できないようにします。

Xcode Release Notes

Two new build settings have been added to enable Swift compiler options:
-suppress-warnings (SWIFT_SUPPRESS_WARNINGS)
-warnings-as-errors (SWIFT_TREAT_WARNINGS_AS_ERRORS)

These settings are independent of the build settings for the corresponding clang options. (24213154)

方法: Xcode の Build Settings で変更（No → YES）

SWIFT_TREAT_WARNING_AS_ERRORS で検索すると見つけやすいです。

こうすると、これまでは警告で無視できたものがエラーになって無視できず、コードを修正しない限りリリースできなくなります。

一方、開発現場では

Optional(2018)年あけましておめでとうございます | Engineers' Blog

非常に大きなサイズの PR であったことや、破壊的変更が行われた Swift 3 への対応だったこと、そもそも古くから運用されているプロダクトであるがゆえの大量の警告を全て潰しきれておらず、そのまま埋もれてしまったとしか言いようがなく、とても恥ずかしい限りです。

たしかに理想は「リリース前に対処しておくべき」ですが、開発現場ではこのようにさまざまな事情があるでしょう。

転職がさかんな業界ですのでどういう経緯で警告を無視してきたのか誰もわからない現場もありそうです。

まとめ

ここで紹介した SWIFT_TREAT_WARNING_AS_ERRORS = YES にすることはあくまで対策のひとつです。

そうしなくても、警告はすべて確認して解消していくべきですね。