Remove bridging conversion behavior from dynamic casts

この提案は Rejected（却下） となりました。動的キャストから Cocoa 橋渡し変換を剥がすという方向性そのものは実装されず、現在の Swift でも as? / as! / is は String / NSString 間の橋渡しや、Error ↔ NSError の橋渡しを従来どおり担っています。

それでも、提案の要点を押さえておくと、「なぜ動的キャストに橋渡しが混ざっているのか」「将来また議論になりそうな論点は何か」を理解する助けになります。

提案されていた内容（採用されなかったもの）

Joe Groff による提案の核は次の3点でした。

• as? / as! / is を 純粋な型チェック専用 に戻す。具体的には、先に挙げた役割のうち「Cocoa 橋渡し変換」「ErrorProtocol 適合型と NSError の相互変換」を動的キャストから取り除く。
• as 演算子も、橋渡し専用の特別扱い（string as NSString など「暗黙変換がないのに as が通る」形）をやめ、通常の型注釈としての役割だけに戻す。
• 動的キャストから取り除いた機能は、型の通常のイニシャライザ として再提供する。

結果として、動的キャストは「今その値が指定の型として扱えるか」を判定するだけの、予測可能で軽い操作になるはずでした。

置き換え API として想定されていた形

橋渡しは値を保ったままの変換なので、標準ライブラリの慣習であるラベル無しの init(_:) で提供する、という方針が採られていました。

extension String {
    init(_ ns: NSString) {
        self = ._unconditionallyBridgeFromObjectiveC(ns)
    }
}

extension NSString {
    // factory init が使える前提のイメージ
    factory init(_ string: String) {
        self = string._bridgeToObjectiveC()
    }
}

NSError については、ErrorProtocol 適合型から作るイニシャライザを Foundation オーバーレイが提供する想定です。

extension NSError {
    factory init(_ error: ErrorProtocol) {
        self = _bridgeErrorProtocolToNSError(error)
    }
}

NSError を特定の Swift エラー型に復元する側は失敗可能イニシャライザで表現されます。

public protocol _ObjectiveCBridgeableErrorProtocol: ErrorProtocol {
    init?(_ bridgedNSError: NSError)
}

Array / Dictionary / Set のように要素型の橋渡し可否で成否が決まるコンテナは、失敗可能イニシャライザを使います。

extension Array {
    init?(_ ns: NSArray) {
        var result: Array? = nil
        if Array._conditionallyBridgeFromObjectiveC(ns, &result) {
            self = result!
            return
        }
        return nil
    }
}

従来 object as! Array<T> が持っていた 遅延橋渡し（要素アクセス時に型を検査し、ミスマッチならトラップ）は、意図が分かるラベルを付けた別のイニシャライザとして切り出す案でした。

extension Array {
    init(forcedLazyBridging object: NSArray) {
        var result: Array? = nil
        Array._forceBridgeFromObjectiveC(object, &result)
        self = result!
    }
}

こうしておけば、Array<T>(object)! は「即時に変換してそれに失敗したらトラップ」という一般的な x as! T ≡ (x as? T)! の関係と揃い、「遅延でよければ Array<T>(forcedLazyBridging: object) と明示する」という形で両者を区別できる、というのが狙いでした。

さらに AnyObject から Swift の値型へ一段で取り出したいケース（[AnyObject] や [NSObject: AnyObject] の要素の取り出し）向けに、プロトコル拡張で汎用的な失敗可能イニシャライザを用意する案もありました。

extension _ObjectiveCBridgeable {
    init?(bridging object: AnyObject) {
        if let bridgeObject = object as? _ObjectiveCType {
            var result: Self? = nil
            if Self._conditionallyBridgeFromObjectiveC(bridgeObject, &result) {
                self = result!
                return
            }
        }
        return nil
    }
}

catch let x as NSError のように「Swift の任意エラーを NSError として扱いたい」用途が多い点については、ErrorProtocol 自身に domain / code / userInfo を生やして、わざわざ NSError に橋渡ししなくても必要な情報が取れるようにしておく、というフォローも同時に提案されていました。

extension ErrorProtocol {
    var domain: String { return NSError(self).domain }
    var code: Int { return NSError(self).code }
    var userInfo: [NSObject: AnyObject] { return NSError(self).userInfo }
}

扱わないと明言されていた範囲

動的キャストに残る「言語の暗黙変換を追随する」挙動、すなわち Optional をくぐる挙動や Array / Dictionary / Set の共変な要素キャストについては、この提案の対象外 とされていました。これらはコンパイル時の暗黙変換ルールとセットで議論すべきという位置づけです。

却下の経緯

この提案は Swift 3 のレビュー期間に取り上げられたものの、レビュー中に Swift 3 への取り込みが defer（先送り） と判断され、後に先送りされた一連の提案をまとめて clean up する流れの中で最終的に Rejected となりました。そのため現在の Swift でも、

• value as? NSString や value as? String のような動的キャスト経由の橋渡し、
• catch let error as NSError による Swift エラーから NSError への変換、
• Array / Dictionary / Set とその NS 系クラスとの as? / as! キャスト

はいずれも生きており、イニシャライザ中心の API 体系には置き換わっていません。ただし提案の動機だった「as? / as! / is に橋渡しが混ざっていることの分かりにくさ」は今なお残っており、同種の議論が再度持ち上がったときの出発点として、この提案の整理は引き続き参照する価値があります。