複数文クロージャのパラメータ/結果型推論を有効にする

複数文クロージャでも、本体から推論された情報を外側の式に伝播できるようにします。これにより単一式クロージャとの差がなくなり、「文が増えた瞬間に型検査が失敗する」崖が解消されます。

推論のルール

新しいルールでは、複数文クロージャのパラメータ型と戻り値型の推論は次のように行われます。

• クロージャの 文脈から与えられた型 が最優先の情報源です。クロージャが代入される変数の型やクロージャを受け取る関数のパラメータ型などから推論されます。
• 文脈から情報が得られない場合、匿名パラメータ（$0 など）は最初に使われた箇所で型が決まり、その型がそのクロージャ全体で固定されます。以降の文で矛盾する型を要求するとあいまいとしてエラーになります。
• 最初の return 文の型が戻り値型を決めます。以降の return 文で異なる型を返そうとするとエラーになります（文脈型がある場合はそちらが優先）。
• return 文がひとつも無いクロージャの戻り値型は、従来どおり Void にデフォルトされます。
• inout のパラメータは、従来どおり文脈型かパラメータ宣言で明示する必要があります。複数文クロージャの本体からの inout の推論・逆伝播は今回のスコープ外です。

クロージャ本体自体の型検査は従来どおり「上の文から下の文へ」一方向に進み、あとの文の情報が前の文の推論に影響することはありません。関数・サブスクリプト・getter などと同じく、最初に決まった型がそのまま宣言の型になる、という一貫したモデルです。

動作例

冒頭のロガー付きの例は、新しいルールのもとでは素直に型検査できます。doSomething($0) の引数型から $0 が Int に推論され、return 文が無いのでクロージャの戻り値型は Void にデフォルトされます（関数 map の T も Void に決まります）。

func map<T: BinaryInteger>(fn: (Int) -> T) -> T {
  return fn(42)
}

func doSomething<U: BinaryInteger>(_: U) -> Void { /* processing */ }

let _ = map {
  logger.info("About to call 'doSomething(\($0))'")
  doSomething($0)
}

if と複数の return を含む次のコードも新しいルールで型検査できます。

struct Box {
  let weight: UInt
}

func heavier_than(boxies: [Box], min: UInt) -> [UInt] {
  let result = boxies.map {
    if $0.weight > min {
       return $0.weight
    }

    return 0
  }

  return result
}

最初の return $0.weight から戻り値型が UInt と決まり、その情報が次の文の整数リテラル 0 に伝わって UInt として扱われます。そのうえで result の型は [UInt] となり、外側の式にまで推論結果が伝播します。同じことは map の結果にさらに filter を繋いだような、より複雑な式でも成り立ちます。

func precisely_between(boxies: [Box], min: UInt, max: UInt) -> [UInt] {
  let result = boxies.map {
    if $0.weight > min {
       return $0.weight
    }

    return 0
  }.filter {
    $0 < max
  }

  return result
}

オーバーロード解決への影響

複数文クロージャ本体の情報が外側に伝わるようになるため、オーバーロードされた関数の呼び出しで、これまでは複数文クロージャなら通っていたコードが新しいルールではあいまいになることがあります。たとえば次のように test が UnsafePointer<PtrTy> を受け取るものと UnsafeRawBufferPointer を受け取るものでオーバーロードされている場合、

func test<PtrTy, R>(_: (UnsafePointer<PtrTy>) -> R) -> R { ... }
func test<ResultTy>(_: (UnsafeRawBufferPointer) -> ResultTy) -> ResultTy { ... }

let _: Int = test { ptr in
  print(ptr) // 本体に無関係な文を足しても...
  return Int(ptr[0]) << 2
}

旧ルールでは本体が型検査に参加しないので最初のオーバーロードから PtrTy を推論できず、結果として曖昧さなく解決されていました。新ルールでは return 文から PtrTy を Int と推論できてしまうため、単一式クロージャのときと同様にあいまいと判定されます。こうしたケースでは、呼び出し側で ptr: UnsafePointer<Int> や UnsafeRawBufferPointer のようにパラメータ型を明示するのが解決策です。