Drop NS Prefix in Swift Foundation

Foundation の多くの型から Swift 上での NS プレフィックスを外し、あわせて関連する列挙体や定数を Swift らしい形に整理します。Swift 3.0 で実装されています。変更は Swift から見たときの名前だけ に関するもので、Objective-C 側の API には影響しません。

NS を外すかどうかのルール

今後新しく Foundation に追加される型を含めて、次の基準で判断します。

1. Objective-C ランタイムや NS 名前空間そのものと結びついた型は、NS を残します。例: NSObject、NSAutoreleasePool、NSException、NSProxy。
2. 実体が AppKit / UIKit など上位フレームワークの領域に属するプラットフォーム固有の型は、それらのフレームワークがプレフィックスを維持しているのに合わせて、NS を残します。例: NSUserNotification、NSBackgroundActivity、NSXPCConnection。
3. SE-0069 によって値型版が用意されている型は、クラス側に NS を残します。値型側が Date や Data のようにプレフィックスなしの名前を担当し、クラス側の NSDate / NSData は引き続き存在します。

既存の型についてはさらに次のルールを加えます。

1. 近い将来に値型版が追加される見込みの型は、先回りして NS を残します。例: NSAttributedString、NSRegularExpression、NSPredicate。
2. NSLock 系のロック用クラス・プロトコルは、今後の並行処理の整理の中で見直されることが見込まれるため NS を残します。
3. NSCache、NSMapTable、NSHashTable、NSOrderedSet のような、オブジェクト限定のコレクション系は、将来的に struct 化される可能性があるため NS を残します。
4. 単にプレフィックスを外すだけでなく、役割を表すより適切な名前に改名する型もあります。例: NSTask は Process へ。

これらのルールに当てはまらない型は、Swift 上での名前から NS が外れます。

代表的な改名

たとえば次のような型が、Swift から見える名前を変えます（いずれも Objective-C 側の NSBundle などの名前はそのまま）。

Objective-C 時代のコードが次のように書き換わるイメージです。

// 従来
let manager = NSFileManager.defaultManager()
let formatter = NSDateFormatter()
let center = NSNotificationCenter.defaultCenter()

// Swift 3 以降
let manager = FileManager.default
let formatter = DateFormatter()
let center = NotificationCenter.default

NSTask から Process への改名は、標準ライブラリに既存の Process 型（プログラムの起動引数などを取得する enum）があるため、そちらを廃止して ProcessInfo に統合した上で、Foundation 側が Process の名前を引き取る、という整理で実現されています。

また NSOutputStream は OutputStream になりますが、これも標準ライブラリの既存の OutputStream プロトコル（テキスト出力先を表す型）と名前が衝突します。そちらは TextOutputStream へ改名され、空いた OutputStream の名前を Foundation の新しい入出力ストリーム型が担当します。

入れ子になった列挙体・定数の整理

Objective-C 流の NSDateFormatterShortStyle や NSJSONReadingMutableContainers のような、クラス名を重ねた列挙体・定数は、対応する Swift 型の中に入れ子にした上で、名前から重複部分を落とします。

// 従来（イメージ）
let style: NSDateFormatterStyle = .NSDateFormatterShortStyle
let options: NSJSONReadingOptions = .MutableContainers

// Swift 3 以降
let style: DateFormatter.Style = .short
let options: JSONSerialization.ReadingOptions = .mutableContainers

たとえば DateFormatter.Style は .none / .short / .medium / .long / .full の 5 つのケースを持つ入れ子の enum になり、NSComparisonPredicate 関連の NSComparisonPredicateOptions や NSPredicateOperatorType は、それぞれ ComparisonPredicate.Options / ComparisonPredicate.Modifier / ComparisonPredicate.Operator のような入れ子型として整理されます。XMLDocument.ContentKind、XMLNode.Kind、XMLDTDNode.Kind のように XML 関連の Kind 系も同じ方針です。

こうした入れ子化により、

DateFormatter.Style.short
JSONSerialization.ReadingOptions.mutableContainers
ComparisonPredicate.Operator.beginsWith

のように「どの型に属する設定なのか」が型名から自然に読み取れるようになります。

NSStringEncoding と String.Encoding

NSStringEncoding は、NSUTF8StringEncoding / NSASCIIStringEncoding などの UInt 定数が並ぶだけの typealias として公開されていました。これを String.Encoding という RawRepresentable な struct に作り直し、各エンコーディングはその static メンバとして提供します。

// 従来
let encoding: NSStringEncoding = NSUTF8StringEncoding

// Swift 3 以降
let encoding: String.Encoding = .utf8

let s = String(data: data, encoding: .utf8)
let d = "hello".data(using: .utf8)

これにより、「エンコーディングを表す型」と「具体的なエンコーディング値」の関係が、他の Swift の enum / OptionSet 型と揃った形で表現されます。

プレフィックスを残す型の使い方

NSObject、NSAttributedString、NSRegularExpression、NSPredicate、NSCache、NSLock、NSXPCConnection のように NS が残る型は、Swift からも従来どおり NS 付きの名前で利用します。これらは前述のいずれかのルール（Objective-C ランタイムと強く結びつく、プラットフォーム固有、値型版の追加が見込まれる、将来的な再設計が想定される、など）に当てはまるため、名前を動かさないほうが長期的に一貫すると判断されたものです。

NSArray / NSString / NSDictionary も同様で、Swift から日常的に使うのは値型の Array / String / Dictionary であり、Objective-C の API を経由するときに NSArray などの名前がそのまま見えるという関係になっています。

既存コードへの影響

Swift 側の型名が大きく変わるため、この提案に対応したツールチェインでは、既存のすべての Swift プロジェクトが新しい名前へのマイグレーションを必要とします。Xcode のマイグレータや Fix-it が古い名前を新しい名前に書き換える形で移行が進められました。Objective-C 側のコードには変更はありません。

今日の Swift で当たり前に目にする Bundle、FileManager、URLSession、NotificationCenter、DateFormatter.Style.short、String.Encoding.utf8 といった型名は、この提案で整理された結果として成立しています。