Move @noescape and @autoclosure to be type attributes

Swift 2 までの @noescape と @autoclosure は、パラメータ宣言に対する属性（declaration attribute）として扱われていました。つまり、次のようにコロンの左側、パラメータ名の前に書くスタイルです。

func f(@noescape fn: () -> ()) {}
func f2(@autoclosure a: () -> ()) {}

これらの属性は意味的には「渡されたクロージャの型」に関する性質（エスケープするかどうか、呼び出し側の式を自動でクロージャに包むかどうか）を表していますが、構文上は引数宣言側に張り付いているというずれがありました。このずれが、いくつかの具体的な不便さを生んでいました。

関数型として書けない

SE-0002 でカリー化された関数宣言構文が取り除かれた影響で、カリー化された形の関数を手で書くコードが使えなくなるケースが出てきました。たとえば、次のような flatMap のラッパーを手書きで書こうとしたとします。

func curriedFlatMap<A, B>(x: [A]) -> (@noescape A -> [B]) -> [B] {
  return { f in
    x.flatMap(f)
  }
}

この書き方は、@noescape がパラメータ宣言にしか付けられなかったため、「関数型の中に @noescape が出てくる位置」で拒否されていました。この問題自体は後に @noescape を任意の関数型にも書けるようにすることで解消されましたが、結果として「宣言にも書けるし型にも書ける」という 冗長な二重表記 が残ってしまっていました。

func f(@noescape fn: () -> ()) {}   // declaration attribute
func f(fn: @noescape () -> ()) {}   // type attribute
// 同じ意味の書き方が2種類ある

@autoclosure では型をまったく書けない

@autoclosure は @noescape よりさらに悪い状況にありました。@autoclosure を含む関数型を、そもそも 明示的な型注記として書き下すことができない のです。

たとえば次のように、@autoclosure を持つ関数を定義して、それを別の変数に代入すること自体は可能です。

func f2(@autoclosure a: () -> ()) {}

let x = f2
x(print("hello"))

このとき x の型は (@autoclosure () -> ()) -> () になっており、わざと型エラーを起こせばコンパイラがその型を表示してくれます。

let y: Int = x
// error: cannot convert value of type '(@autoclosure () -> ()) -> ()' to specified type 'Int'

ところが、同じ型を自分で書こうとすると拒否されてしまいます。

let x2: (@autoclosure () -> ()) -> () = f2
// error: attribute can only be applied to declarations, not types

型推論では扱える型を、手書きの型注記では書けない、という一貫性のない状況でした。

SE-0031 との足並み

同じ時期に行われた SE-0031 では、inout をパラメータ宣言側から型側の修飾子へと移すことで、宣言構文と型構文の位置を揃える整理が進められていました。@noescape と @autoclosure についても同じ方向で整理しないと、宣言と型のあいだの位置関係がキーワードごとにバラバラになってしまいます。