マクロによる async 関数の同期オーバーロードの生成

@Reasync というアタッチマクロを追加し、async 関数の宣言に付けると、コンパイル時に同期版オーバーロードが peer として生成されるようにします。マクロは標準ライブラリ、または swiftlang GitHub 組織配下の公式パッケージのいずれかに置く想定で、置き場所はレビューで決められます。生成された同期版は普通の関数宣言なので、コンパイラのパース・型検査・isolation 検査はいずれも通常どおり適用されます。マクロ自体は実行時には何もしません。

マクロ宣言と基本動作

マクロは peer マクロとして次のように宣言されます。

@attached(peer, names: overloaded)
public macro Reasync()

@Reasync を async 関数に付けると、シグネチャと本体から async / await を取り除いた同期版が、同じ名前の peer 宣言として生成されます。

@Reasync
func run(
    _ body: () async throws -> Void
) async rethrows
{
    try await body()
}

// @Reasync によって生成される:
//
// func run(
//     _ body: () throws -> Void
// ) rethrows
// {
//     try body()
// }

呼び出し側では、SE-0296 で定められた既存のオーバーロード解決ルールに従い、同期コンテキストからは同期版が、async コンテキストからは元の async 版が選ばれます。@Reasync 側に新しい解決規則は持ち込まれません。

変換は本体の全域に再帰的にかかる

@Reasync の変換はシグネチャだけでなく、関数本体やネストした宣言まで広がります。具体的には次のような書き換えが行われます。

• async 関数のシグネチャから async を除く
• クロージャ型のパラメータに付いた async を、ネストの深さによらず除く
• 式中の await を除き、内側の式だけを残す
• async let を通常の let に変える
• for await / for try await から await を除く
• ネストした関数宣言、クロージャ式、ローカル computed property のアクセサに対して同じ変換を再帰的に適用する

たとえば次の sum は、本体内の for ループと await の両方が同期版で書き換えられます。

@Reasync
func sum(
    _       values      : [Int],
    using   transform   : (Int) async -> Int
) async -> Int
{
    var total: Int = 0

    for value in values
    {
        total += await transform(value)
    }

    return total
}

// 生成される同期版:
//
// func sum(
//     _       values      : [Int],
//     using   transform   : (Int) -> Int
// ) -> Int
// {
//     var total: Int = 0
//
//     for value in values
//     {
//         total += transform(value)
//     }
//
//     return total
// }

属性・修飾子・generic 制約・トリビア・ドキュメントコメントは原則そのまま残るので、生成された同期版の見た目は元の async 版とほぼ揃います。元の宣言が別の宣言の本体内にネストしていた場合は、アタッチ位置のインデントに合わせて peer のインデントが正規化されます。

ネストした関数に直接 @Reasync を付けても、外側の @Reasync がすでにその関数を変換しているため、内側の @Reasync は冗長な属性として警告と「属性を取り除く」fix-it の対象になります。

strict concurrency 関連の属性の扱い

Swift 6 で実用上書かれる async 関数には、async 以外の concurrency 関連の注釈もしばしば付きます。マクロは「同期版で意味を成さなくなる」ものを取り除き、それ以外は保持する方針で扱います。

@isolated(any) / nonisolated(nonsending) / @concurrent は、SE-0431 や SE-0461 の規定により、そもそも同期関数や同期関数型に付けられない、あるいは同期関数では意味を持たない注釈です。生成された同期版が成立するためには取り除く必要があります。

@Sendable をパラメータのクロージャ型から外すのは、async 版本体が async let や TaskGroup で isolation boundary を越えていたケースを同期版が解消する以上、それに伴う @Sendable 要件も同期版からは外したい、という考えからです。async 版が Task ベースで並列実行を別途仕掛けているなど、@Sendable を残すべき例外もあり得ますが、マクロは本体の意味解析ができないため、常に外す方針に統一されています。同期版で @Sendable がやはり必要だった場合は、生成された peer の strict concurrency 検査で診断が出るので、利用者はマクロを諦めて手書きの同期オーバーロードに切り替えることになります。

sending は「関数の値が isolation boundary をどう越えうるか」を表す注釈で、async か同期かに依存しません。グローバルアクター・isolated パラメータ・裸の nonisolated も「関数がどこで動くか」を表すもので async 性とは直交するため、いずれも生成される peer にそのまま引き継がれます。

診断と適用先の制限

@Reasync は適用できる場所が明確に絞られています。

• 同期関数や、関数でない宣言に付けるとエラー（'@Reasync' can only be applied to async functions）
• @Reasync を付けた関数の中にネストした関数へさらに @Reasync を付けると、警告と fix-it を出す（外側のマクロですでに変換されているため）
• プロトコルの要件に付けるとエラー（'@Reasync' cannot be applied to protocol requirements）。これは現状のコンパイラに、生成された同期要件を protocol existential 経由で dispatch するとランタイムクラッシュするバグがあるためで、コンパイラ側の修正後にこの制限を外せる余地が残されています

マクロは AST 上の構文操作だけを行い、本体に書かれた式の意味までは見ません。「async の必要性がクロージャパラメータ以外（actor-isolated なメソッドや async 専用 API の呼び出しなど）に由来する関数」に @Reasync を付けてしまった場合、マクロ自体は同期版を生成し、その後の型検査でエラーになります。診断は展開後のソース上に出るため利用者は展開先の位置で問題箇所を受け取りますが、誤って同期化された関数がそのまま通ってしまうことはありません。

マクロ採用の影響

• すでに公開されている async 関数に @Reasync を付けるのは、クライアントから見ると同期版オーバーロードが増えるだけなので、ソース互換に保たれます
• 一度生成された同期版オーバーロードを使い始めたあとで @Reasync を外すのは、ソース破壊的変更になります。同期版を公開した時点で、それ自体をライブラリの公開 API として扱うべきです
• マクロはコンパイル時に通常の関数宣言へ展開されるだけなので、ABI には影響しません。@Reasync を外して同期版を直接書き直しても、生成された peer と同じ ABI のため、クライアント側の影響なしに移行できます