メンバーimport可視性

メンバー宣言の可視性ルールをトップレベル宣言と揃え、そのソースファイルから「見えている」モジュールが宣言したメンバーだけがスコープに入るようにします。言い換えると、あるメンバーを使うには、それを宣言しているモジュールをそのファイルで直接インポート（またはそれに準ずる形で可視化）していなければなりません。

この新しい挙動は、将来の言語モードで既定となるほか、それより前のモードでも upcoming feature flag MemberImportVisibility を有効にすることで先取りして使えます。

「可視なモジュール」の定義

あるソースファイルから可視なモジュールは、トップレベルの名前解決で従来から使われているルールと同じ集合になります。具体的には次のいずれかに当てはまるモジュールです。

• そのソースファイル内の import 文で直接インポートされているモジュール
• そのファイルに対応する bridging header からインポートされているモジュール
• 上記のいずれかで直接インポートされたモジュールから 再エクスポート（re-export） されているモジュール

再エクスポートは「このモジュールを import したクライアントに別のモジュールも見えるようにする」仕組みです。Clang モジュールでは modulemap の export * などで広く使われています。Swift モジュール側には公式な再エクスポート構文はありませんが、コンパイラ内部で @_exported 属性が用いられることがあります。再エクスポートは推移的にも働くため、A が B を、B が C を再エクスポートしていれば、import A だけで A / B / C の宣言が見えます。

なお、コンパイラが暗黙にインポートする標準ライブラリや「現在ビルド中のモジュール自身」も可視モジュールに含まれます。その副作用として、自分のモジュールが（どこかのソースファイルで）再エクスポートしているモジュールは、自分のモジュールのどのソースファイルからも見えることになります。

挙動の例

先ほどの main.swift の parse() の例では、MemberImportVisibility を有効にすると、main.swift で GroceryKit をインポートしていない以上、GroceryKit の parse() は候補に上がらなくなり、曖昧性は発生しなくなります。逆に、従来は推移的インポートだけに頼って使えていたメンバーは使えなくなります。

// RecipeKit は別ファイルで import されているが、このファイルでは import していない
let recipe = "1 scoop ice cream, 1 tbs chocolate syrup".parse()
// error: instance method 'parse()' is inaccessible due to missing import of defining module 'RecipeKit'
// note: add import of module 'RecipeKit'

このようにエラーメッセージは「どのモジュールを import すれば解決するか」を指摘してくれ、fix-it として直接インポートの追加が提案されます。移行の際はこの fix-it を当てていくのが基本的な作業になります。

SE-0409 との関係と併用

import 宣言自体のアクセス修飾子（public import / internal import など）を扱う SE-0409 と本提案は補完関係にあります。SE-0409 はインポートの アクセスレベル を、本提案はインポートの スコープ（どのファイルから見えるか） を統制するもので、両方を組み合わせることで「他モジュールから持ち込まれる宣言」の露出をよりきめ細かくコントロールできます。

プロトコル適合に対する例外（採択された修正）

本提案を素直に適用すると、プロトコルへの適合（conformance）を書いたソースファイルでは、各要件のwitnessとなるメンバーがそのファイルから可視でなければなりません。しかし「ライブラリ側がプロトコルに新しい要件と既定の実装を同時に追加した」ようなケースでは、適合を書いているクライアント側に既定実装の存在は伝わらないため、ファイル単位の可視性ルールに従わせると 既存の適合が突然壊れる ことになります。

この問題に対応するため、本提案には後から修正（amendment）が加えられ、次の条件を満たす 既定の実装 はファイルからimportされていなくても要件のwitnessとして採用されてよい、と整理されました。

1. その既定実装が、要件を宣言しているプロトコルの 無制約な（unconstrained）エクステンション に書かれている
2. そのエクステンションが、プロトコル本体と 同じモジュール に属している

// 外部モジュール: GroceryKit
public protocol GroceryItem {
  var name: String { get }       // 既存の要件
  var aisle: String? { get }     // 新しく追加された要件
}

extension GroceryItem {
  public var aisle: String? { nil } // 既定実装
}

// ShoppingList.swift（GroceryKit を import している）
import GroceryKit
internal protocol ShoppingListItem: GroceryItem { }

// IceCream.swift（GroceryKit を import していない単純なモデルファイル）
struct IceCream: ShoppingListItem {
  var name: String { "Ice cream" }
  // aisle 要件は GroceryKit 側の既定実装で自動的に満たされる
}

この例外は、library evolution を有効にしたモジュールがプロトコルに要件を追加したときに、ランタイムで既定witnessとなる実装の選び方とも整合しています。結果として、ライブラリ作者はプロトコルを進化させてもクライアントのソース互換性とABI互換性をまとめて保てるようになります。