Controlling function definition visibility in clients

関数の「呼び出し可能なシンボルをバイナリに出すか」「定義をクライアントに見せるか」を明示的に制御する新しい属性 @export を導入します。@export は引数にいずれかひとつを取ります。

• @export(interface): バイナリに呼び出し可能なシンボルを 必ず 生成し、定義はクライアントに 一切見せない。
• @export(implementation): 定義をクライアントに利用可能にする（特殊化・インライン化・解析に使える）。モジュール側に呼び出し可能なシンボルは出さないため、利用するクライアントは自分で定義のコピーをエミットする。

どちらの指定もコンパイルモード（Library Evolution か、WMO か、Embedded Swift か）に左右されず、作者の意図を固定します。@export は引数なしでは使えず、interface と implementation を同時に指定することもできません。

既存属性との対応

新属性は、既存のアンダースコア付き属性と @inlinable の役割を整理し直します。

• @_alwaysEmitIntoClient → @export(implementation) に統合されます。
• @_neverEmitIntoClient → @export(interface) に統合されます。
• @inlinable / @usableFromInline は @export と 部分的に 重なります。@inlinable は Library Evolution 下ではシンボル生成を保証しますが、それ以外では保証しません。@usableFromInline もシンボル生成を保証せず、しかも定義の露出を禁止することもできません。@export(interface) / @export(implementation) はこれらを保証します。

@export は @inlinable / @usableFromInline / @_alwaysEmitIntoClient / @_neverEmitIntoClient のいずれとも 併用できません。

アクセス制御とは直交

@export はアクセス制御（public / internal / private など）とは独立した軸です。ソースコードから参照できるかはアクセス制御が決めますが、コンパイラから定義が見えるかどうかは最適化モード次第で変わるため、そこを別に固定するのが @export の役割です。

// モジュール A
private func secret() { /* ... */ }

public func f() {
  secret()
}

// モジュール B
import A

func g() {
  f()
}

モジュール B から secret をソースで呼ぶことはできませんが、Embedded Swift や積極的 CMO の下では f() の定義を介して secret まで B 側でインライン化される可能性があります。これを防ぎたい場合は、たとえば次のように書けます。

• f に @export(interface) を付け、f の定義自体をクライアントに見せない。
• あるいは secret に @export(interface) と @inline(never) を付け、必ず独立したシンボルを持たせて f にも一切インライン化させない（private のままソースからは触れない）。

@inline(always) / @inline(never) との関係

@inline(always) / @inline(never)（SE-0496）は、コンパイラに「インライン化するかどうか」を指示する属性で、「シンボルを出すか」「定義をクライアントに見せるか」とは直交した概念です。@export と組み合わせることができます。主な組み合わせの意図はたとえば次のとおりです。

• @export(implementation) + @inline(always): ABI には載せない、性能のため必ずインライン化したい関数。
• @export(implementation) + @inline(never): ABI には載せないが、インライン化する必要はない関数。
• @export(interface) + @inline(never): 実装を完全にカプセル化し、リンク時に差し替え可能にしたい関数。他のコードに影響せず実装だけを入れ替えられる。
• @export(interface) + @inline(always): モジュール内ではインライン化され、モジュール外からはシンボル経由で呼ばれる。

Embedded Swift での制約

Embedded Swift はすべてのジェネリック関数を呼び出しごとに 具体型で特殊化（monomorphize） してコードを生成します。ジェネリック関数は単一のシンボルで済ませられないため、@export(interface) と 組み合わせることはできません。

// モジュール A
public func fGeneric<T>(_ value: T) { /* ... */ }

// モジュール B
func h() {
  fGeneric(MyType()) // fGeneric<MyType> に特殊化する必要がある
}

stored property や型への適用

@export は関数だけでなく、stored property や型にも付けられます。

• stored property / 型 + @export(interface): ストレージ用シンボルや型のメタデータを、使われた時点で遅延生成するのではなく eager に 生成する。Embedded Swift では通常こうしたシンボルは参照されるまで出力されないため、この指定で明示的に出力を強制できる。
• 型 + @export(implementation): Library Evolution 下の @frozen に近い意味合い（レイアウト情報をクライアントに見せる）になるが、Library Evolution の外では @frozen に相当する概念がないため、現時点では限定的。

Future Directions（参考）

提案では、今回のスコープ外として以下の方向性が speculative に挙げられています。いずれも将来的な可能性であって、実現を約束するものではありません。

• 可視性の拡張: GCC の visibility 属性や Visual C++ の dllimport / dllexport に相当する指定を、@export(interface, visibility: hidden) のような形で追加する方向。
• internal / private import と組み合わせた実装隠蔽の自動化: SE-0409 の future direction として示されている「非 resilient なモジュールでも transitive な依存を自動で隠す」挙動が入れば、今回 @export(interface) で手動に行っている transitive 依存の遮断を、明示せずとも得られるようになる。
• @export(interface, implementation) の解禁: 当初は両方同時指定も認めていましたが、Library Evolution 下では @inlinable と同じで、それ以外の状況では @inlinable を置き換えるほどの用途がなかったため、今回は禁止されています。将来具体的な用途が見つかれば、この制限を外すことはできます。