型プレースホルダ（旧称”Placeholder types”）

型を書ける位置に、その部分だけ推論に任せたいことを示す type placeholder（アンダースコア _）を書けるようにします。型のうち必要な骨格だけをプログラマが与え、残りは従来どおり型推論に委ねるという書き方が可能になります。

先ほどの Double.init の例は、戻り値を _? にして次のように書けます。

let losslessStringConverter = Double.init as (String) -> _?

ジェネリック型の例も、推論できる側を _ にして書き分けられます。

let publisherOrValue = Either<_, Int>(left: makePublisher())

書ける場所

文法上、type placeholder は型が書ける場所ならどこにでも書けます。

Array<_>       // 要素型が placeholder の配列
[Int: _]       // 値型が placeholder の辞書
(_) -> Int     // 引数型が placeholder の関数型
(_, Double)    // placeholder と Double のタプル
_?             // placeholder をラップするオプショナル

型チェッカは placeholder 以外の部分をこれまでどおり解釈し、placeholder の箇所は「ユーザーが明示した無名の型変数」として扱って、周囲の文脈から解決しようとします。たとえば次のコードでは、

import Combine

func makeValue() -> String { "" }
func makeValue() -> Int { 0 }

let publisher: AnyPublisher<Int, _> =
    Just(makeValue()).setFailureType(to: Error.self).eraseToAnyPublisher()

AnyPublisher の Failure は setFailureType(to: Error.self) から自明に Error と決まるので placeholder にしておき、一方で Output == Int という情報を与えることで makeValue() のオーバーロードが Int を返す方に解決されます。

型制約の扱い

placeholder がプロトコルへの適合を要求される文脈にあっても問題ありません。

let dict: [_: String] = [0: "zero", 1: "one", 2: "two"]

ここでキーの型 placeholder には Hashable への適合が要求されますが、型チェッカは placeholder が必要な制約を満たすと仮定したうえで推論を進め、最終的に決まった型について制約を検証します。

ジェネリック引数の省略との関係

もともとSwiftでは、文脈からジェネリック引数を推論できる場合に型名だけを書くことが許されています。

import Combine
let publisher = Just(0) // Just<Int> が推論される

この提案のもとでは、素の型名を書くことは、ジェネリック引数をすべて placeholder で埋めるのと等価に扱われます。上の例は次と同じ意味になります。

let publisher = Just<_>(0)

トップレベルでは使えない

型全体が placeholder だけになる書き方は許されません。

let percent: _ = 100.0
// error: placeholders are not allowed as top-level types

関数シグネチャでは使えない

関数の引数型と戻り値型は、これまでどおり完全に書く必要があります。プロトコル要件やデフォルト引数式から推論できそうに見えても、シグネチャの中に placeholder を書くことはできません。

func doSomething(_ count: _? = 0) { ... } // error

これは、次のようにジェネリック型の名前だけを書くのが認められていないのと同じ扱いです。

func doSomething(_ count: Optional = 0) { ... } // error

関数の本体の中であれば、もちろん placeholder を使えます。たとえば次の Bar の例では、シグネチャに placeholder を含む frobnicate2 / frobnicate4 / frobnicate5 / frobnicate7 / frobnicate8 はエラー、本体の式の中でのみ placeholder を使う frobnicate3 / frobnicate6 はOKです。

struct Bar<T, U>
where T: ExpressibleByIntegerLiteral, U: ExpressibleByIntegerLiteral {
    var t: T
    var u: U
}

extension Bar {
    func frobnicate3() -> Bar {
        return Bar<_, _>(t: 42, u: 42) // OK
    }
    func frobnicate6() -> Bar {
        return Bar<_, U>(t: 42, u: 42) // OK
    }
}

動的キャストでの扱い

is / as? / as! のような動的キャストでは、キャスト元の式とキャスト先の型の間に型推論上の結び付きがありません。文法上 placeholder を禁止はしませんが、推論の手がかりがないため、たとえば 0 as? [_] のような書き方はほとんどの場合型チェックに失敗します。case let y as [_] のような is / as パターンも同様です。

API / ABI への影響

type placeholder はAPIとして外に露出しません。コンパイル済みインターフェースでは、@inlinable な関数本体やデフォルト引数式を除き、placeholder はその場で推論された型に置き換えられます。ライブラリ側で placeholder を使うかどうかは実装の詳細ですが、placeholder を挟むことによって推論結果の型が変わってしまうとAPI／ABIの破壊につながり得るため、導入・除去時にはそこだけ注意が必要です。