（承前）
高級言語を安全で使いやすくしている機能は、それゆえに速度の低下を招いてしまうものなの
である。偶然にもSwiftとJavaScriptの両方で動作する、次のコードを検討してみよう。
////////////////////////////////////////////////////////////
var c = a + b // this needs to be fast
////////////////////////////////////////////////////////////
CPUには、二つの数値を足し合わせる命令が備わっている。Cのような低級言語では、整数は
「整数である」と明確に宣言しなければならず、CPUがそのまま利用できるようなフォーマッ
トでメモリに保存される。Cが採用したこの手法の利点は、整数がCPUのADD命令によって直
接操作できるということである。2つの整数を加算するCのコードからコンパイラが生成するの
はまさにこのADD命令に他ならない。
一方、JavaScriptのような言語では、var c と宣言してもそれで有効である。なぜかという
と、JavaScriptの変数は数値や文字列、そしてオブジェクトといったあらゆる値を格納するこ
とができる（「何もない」という値さえ保持できる）からだ。JavaScriptのコンパイラは、上
掲コードの変数aとbに入っているのが数値なのかどうか判断する術がないので、a + b という
コードから単純にCPUのネイティブ命令であるADDを生成することはできない。
（承前）
変数に格納されている値の型がソースのコンパイル時に決定できないのであれば、それはプロ
グラムの実行時に決定しなければならない。さらに、もし２変数のいずれかに数値が入ってい
ない、あるいは両者にそれぞれ違う種類の数値が入っている場合には、二つを適切な型に変換
するための処理を追加で実行しないといけない。
JavaScripotでは、+という単純な演算子でさえ意味が状況依存的だ。もし a + b という式でa
が文字列であれば、+演算子は数値の加算ではなく、文字列の結合という処理を実行するのが
正しい。
大事なのは、こうした判断がプログラムの実行中に行われるということだ。JavaScriptエンジ
ンは、コンパイル時に生成されたADD命令を単純に実行するのではない。まずはそもそも何を
すべきなのかを判断するためだけに、数十、あるいは数百の命令を実行しなければいけないの
だ。
もし二つの整数値を加算するために数十のCPUサイクルを消費するようでは、Swiftが「シス
テム開発のための業務に耐える言語」になることなど到底不可能である。この問題を解決する
には、CやObjective-Cのように、Swiftのすべての変数、関数の引数、そして戻り値の型を明
示的に宣言させるのが最良の方法だ。そうすればコンパイラは a + b というコードが何をして
いるのか、そしてどの意味で+演算子を使えばいいのかが分かる。
（承前）
確かにそれはそうなのだが、これまで示してきたSwiftのコードでは一度も型宣言が行われてい
ない。私は２年前に、型の明示的宣言なしに変数の型を推定する本格的な型推論※機能が
Objective-Cに盛り込まれるのではないかと推測した。その代わりに登場したのがSwiftであ
る。Swiftは、その目的達成のために型推論に強く依存している。
※型推論：
ttp://www.wikipedia.com/ja/%E5%9E%8B%E6%8E%A8%E8%AB%96
次のSwiftコードで宣言されている変数は、JavaScriptで同じことをした場合と同様、どの型の
値でも保持できるというわけではない。Swiftの各変数は、宣言で代入されている値によってコ
ンパイル時に型が推測され、強制的にその型が付与される。
////////////////////////////////////////////////////////////
var name = "Bob" // String
var cars = 2 // Int
var temp = 88.2 // Double
////////////////////////////////////////////////////////////
（承前）
しかしここからが絶妙なのだ。先に述べたように、これらの基本的な型はSwiftという言語の一
部ではなく、標準ライブラリの一部としてSwiftコードによって定義されている。なのでSwift
のコンパイラは、変数carsの型がIntであると分かったとしても、もっと基本的なことを分かっ
ていないのである。つまりIntとは一体何なのだ、ということだ。
Swiftコンパイラは標準ライブラリを漁ってInt型を実装しているコードを探し、コンパイルす
るので、Intというものの存在や、それに何のメソッドが適用できるか、といったことは知って
いる。しかし、IntがSwiftという言語の一部ではないとすれば、コンパイラはInt型の変数を
CPUのADD命令に直接食わせても安全なのかどうか、どのように判断すればいいのだろうか。
もう一つ問題がある。標準ライブラリにはIntに適用できる全ての 演 算 も定義されてお
り、そのコードはSwiftで書かれている。最も基本的な型がライブラリで定義されていること、
そして、定数がそれらの型のいずれかを自動的に付与されることを踏まえれば、Swiftには絶対
に演算子のオーバーロード※機能が必要である。よく批判※の対象になる機能だが、これをサポ
ートしていなければ、Swiftは２整数の加算という単純なコードさえコンパイルできなくなる。
※演算子のオーバーロード：
ttp://www.wikipedia.com/en/Operator_overloading
※批判：
ttp://www.wikipedia.com/en/Operator_overloading#/Criticisms
（承前）
ここで先の a + b の例に戻る。整数値をもつ２つの変数があり、それが+演算子で結ばれてい
ると仮定しよう。Swiftのコンパイラは、標準ライブラリをコンパイルするまで、この２変数に
ついて何も分からない。このコードを、２整数を加算するCのコードのように高速にすること
など可能なのだろうか。
////////////////////////////////////////////////////////////
func add(a : Int, b : Int) -> Int {
return a + b
}
////////////////////////////////////////////////////////////
（承前）
Swiftのコンパイラswiftcは、上の関数から次のようなアセンブリコードを生成する（コメント
は後から追加）。（「__TF3add3addFTSiSi_Si」というラベルは、add()関数のためにコンパ
イラが生成した名前である。以後このような自動生成名がいくつも登場する。頭がおかしい※
ように見えるが、ここでは気にする必要はない。）
※頭がおかしい名前が必要な理由：
ttps://www.mikeash.com/pyblog/friday-qa-2014-08-15-swift-name-mangling.html
///////////////////////////////////////////////////////////////////////
__TF3add3addFTSiSi_Si:
pushq %rbp ; standard function prologue
movq %rsp, %rbp ; standard function prologue
addq %rsi, %rdi ; add two 64-bit integers
jo LBB0_2 ; jump to LBB0_2 if the addition overflowed
movq %rdi, %rax ; put the result in right register for returning
popq %rbp ; standard function epilogue
retq ; return from the function
LBB0_2:
ud2 ; abort on overflow by raising an invalid opcode exception
///////////////////////////////////////////////////////////////////////
（承前）
見よ、燦然と輝くADD命令を！（上下を各２行空けてある。）Swiftのシステムは確かに機能
している。しかし、どのような方法で、なのだろうか。これを詳しく知るには、Swiftのコード
と最終的なアセンブリコードの間にあるものを見ていかなくてはならない。そしてそのために
は、手書きのコードがどのようにして最終的なバイナリに変換されていくのかをもう少し知る
必要がある。
（承前）
下の図は、clang（C/C++そしてObjective-Cに対応する、Appleが開発したLLVMベースのコ
ンパイラ）を使ってx86-64 CPUのためのコードをコンパイルするプロセスを示している。
ttp://cdn.arstechnica.net/wp-content/uploads/2014/10/clang@2x.png
Swiftで書かれた先述のadd()関数から、どのようなLLVM IRを生成したのか表示するよう
swiftcに指示しても、llvm.sadd.with.overflow.i64※という命令が呼ばれていると分かるだけ
で、大した情報は得られない。この命令は、先のアセンブリコードにあったx86-64のaddq命
令をLLVMで表現したものであり、両者は結局同じものにすぎない。我々が知りたいのは、二
つのInt型変数を加算するというコードを見て、なぜコンパイラがLLVM IRあるいはx86-64マシ
ン語で、その高速な64ビットのネイティブ加算命令を使おうと判断できたのか、ということ
だ。
※llvm.sadd.with.overflow.i64：
http://llvm.org/docs/LangRef.html#llvm-sadd-with-overflow-intrinsics （昨日は連続書き込み制限を食らったので全部アップできませんでしたが、ここまで翻訳して
あったのでした。）
（あと、>>84の型推論に関するWikipediaへのリンクが間違っていました。以下が正しいで
す。）
http://ja.wikipedia.org/wiki/型推論
（反応をくれた>>80さんをはじめ、読んでくれている人どうもありがとう。訳が変、あるいはこうすればもっと分かりやすい、ということがあればぜひ教えてください。）
（では、おやすみなさい） 乙です。
翻訳に何日掛かったかはわからないけど凄すぎる
シラクサ好きさんの翻訳楽しみにしてます
丁寧な訳で本当に頭が下がります
（承前）
Swiftのコンパイラは、コンパイル処理の流れの中に新しいステップを追加し、Swift中間言語
(SIL) という新たな中間形態を導入する。下の図はswiftcを使ってSwiftのコードをx86-64 CPU
のためにコンパイルするプロセスである。
ttp://cdn.arstechnica.net/wp-content/uploads/2014/10/swiftc@2x.png
以下はadd()関数のためにswiftcが生成したSILのコードである。（訳注：コードの太字は再現
できないので、原文を参照のこと）
///////////////////////////////////////////////////////////////////////
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
// function_ref Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
%4 = function_ref @_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int%5
%5 = apply [transparent] %4(%0, %1) : $@thin (Int, Int) -> Int
return %5 : $Int
}
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
sil [transparent] @_TFSsoi1pFTSiSi_Si : $@thin (Int, Int) -> Int
///////////////////////////////////////////////////////////////////////
（承前）
add()関数の本体にあった a + b は、二つのInt整数を加算する中置記法※ (infix) 演算子の機能を
実装した関数（コード最下部ににその定義が見える）への参照を取得し、add()に与えられた二
つの引数にその関数を適用する、というSILコードに変換されている。このコードでもう一つ
分かるのは、Swift標準ライブラリが「Swift」と名付けられていることである。標準ライブラ
リにおいてInt型はSwift.Intであり、加算演算子はSwift.+であり・・・といったことが見てとれ
る。
※中置記法：
ttp://ja.wikipedia.org/wiki/中置記法
２数を加算するためにSwift.+を呼び出すのは、かなり低速な処理になるかもしれない。上の
SILコードはいわば「素」のSILであり、最適化が無効にされている場合でも、ここからswiftc
によっていくつかのコード変換処理が行われる。次のコード（コメントは後から追加）は、
swiftcが生成したSwift.+関数だけのSILである。Swift標準ライブラリに収められている通り
の、「原典に忠実な※」コードだ。
（承前）
///////////////////////////////////////////////////////////////////////
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int
sil public_external [transparent] @_TFSsoi1pFTSiSi_Si : $@thin
(Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
// LLVMの組み込み関数 sadd_with_overflow への参照を取得
%2 = builtin_function_ref "sadd_with_overflow_Word" : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1)
// 二つの引数のInt構造体から数値を抽出
%3 = struct_extract %0 : $Int, #Int.value
%4 = struct_extract %1 : $Int, #Int.value
// sadd_with_overflow に食わせるもう一つの整数値（１ビット）の作成
%5 = integer_literal $Builtin.Int1, -1
（承前）
// sadd_with_overflow_Word を呼んで数値を加算する
%6 = apply %2(%3, %4, %5) : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1)
// sadd_with_overflow が戻してきたタプル※から結果を抽出
%7 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 0
%8 = tuple_extract %6 : $(Builtin.Word, Builtin.Int1), 1
// オーバーフローが起きた場合の対処
cond_fail %8 : $Builtin.Int1
// オーバーフローがなかったら、結果をSwift.Int構造体でラップして返す
%10 = struct $Int (%7 : $Builtin.Word)
return %10 : $Int
}
///////////////////////////////////////////////////////////////////////
※タプル：
ttp://ja.wikipedia.org/wiki/タプル
※原典に忠実な：
canonicalという単語の訳である。「素のSILコードにインライン変換などの処理が適用され
た、オプティマイザが最適化を加える前の状態」を比喩的に表現したものと解釈したが、自信
なし。
（承前）
コードが少しややこしくなってきたが、もうすぐ核心部に入るので、どうか付いてきてほし
い。注目は、上のコードで何回も出てくるBuiltinという言葉である。関数
sadd_with_overflow_Wordは、二つのBuiltin.Word型の値（と１つの１ビットブーリアン値）
を引数に取る。ここでsadd_with_overflow_Wordに渡されている二つのBuiltin.Word型の値
は、Swift.+関数に渡されたInt型の引数から抽出されたものだ。
Int型という高レベルの世界と、LLVM IRやその帰結であるマシン語コードという低レベルの世
界とを橋渡しするもの、その大雑把な概要がここで見えてきた。説明に「無限に積み重なる亀
※」は不要だ。各Int構造体がBuiltin.Word型の値を内包しており、それはLLVM IRにおいて直
接に相当する型が存在するほどに十分抽象度が下げられているのだ。
※無限に積み重なる亀：
ttp://en.wikipedia.org/wiki/Turtles_all_the_way_down
（承前）
そして、add()関数のコードから生成された最適化前のSIL（先の「素」の状態の次の段階）を
見れば、パズルの最後のピースが埋まる。このコードには、上掲のSwift.+関数のコードすべて
がインライン展開されている。
///////////////////////////////////////////////////////////////////////
// test.add (Swift.Int, Swift.Int) -> Swift.Int
sil @_TF4test3addFTSiSi_Si : $@thin (Int, Int) -> Int {
bb0(%0 : $Int, %1 : $Int):
debug_value %0 : $Int // let a
debug_value %1 : $Int // let b
// Swift.+ infix (Swift.Int, Swift.Int) -> Swift.Int inlined below
%4 = builtin_function_ref "sadd_with_overflow_Word" : $@thin
(Builtin.Word, Builtin.Word, Builtin.Int1) ->
(Builtin.Word, Builtin.Int1) // user: %8
...
%12 = struct $Int (%9 : $Builtin.Word)
return %12 : $Int
}
///////////////////////////////////////////////////////////////////////
この自動的なインライン展開を制御しているのはtransparent（透明）属性である。前掲のコー
ドでSwift.+関数に付けられていたものだが、気づかれただろうか。
（また連続投稿で弾かれてます。仕方ないのでおやすみなさい。>>92さん>>93さんコメント
ありがとう） （承前）
ここで、ようやくすべてのピースが出揃った。BuiltinはSwiftとLLVM IRの間の橋渡しである。Builtinが表現する型や関数
は、LLVM IRの型※と命令※に直接対応している。transparent属性は、それが必ずインライン展開されるべきプリミティブな
関数であることを示している。Builtinの型を使ってBuiltinの関数を呼び出すSILコードから、LLVM IRのコードを生成するの
は単純な手続きである。Builtin.Word型はLLVM i64型（あるいは、32ビットアーキテクチャ向けのコードならi32型。SILは
LLVM IRよりもアーキテクチャ非依存）に一直線に対応するし、sadd_with_overflow_Wordはllvm.sadd.with.overflow.i64※
というLLVM IRの組み込み命令※にそのまま変換される。他も推して知るべし。
※LLVM IRの型：
ttp://llvm.org/docs/LangRef.html#type-system
※LLVM IRの命令：
ttp://llvm.org/docs/LangRef.html#instruction-reference
※llvm.sadd.with.overflow.i64：
ttp://llvm.org/docs/LangRef.html#llvm-sadd-with-overflow-intrinsics
※組み込み命令：
ttp://llvm.org/docs/LangRef.html#intrinsic-functions
ここまでの検討で、もう一つのことが明らかになる。Swift標準ライブラリは、デフォルトで読み込まれるということを除い
ても、実は少し特別である。Swiftで書かれてはいるが、標準ライブラリはBuiltinの関数と型の世界にアクセスできる唯一の
存在なのである。それに、transparent属性を使って特定の関数を自動でインライン展開するよう指示したりもしている。
（承前）
Swift標準ライブラリのソースコードは非公開なので、以上のことを発見するには自作のSwiftコードから生成されたSILを見
ていかなければならなかった。しかし安心してほしい。BuiltinとtransparentはSwift自身の一部であり、SILだけに限定され
たものではない。Xcode6のアプリケーションバンドル内に埋もれているswiftcのバイナリファイルをstringsコマンド※で見て
みると、-parse-stdlibというオプションの存在が見える。このオプションをつければ、Swiftのコードは標準ライブラリと同
じルールに基づいてコンパイルされるので、Builtinの型と関数の使用が許される。Swiftで書いた関数に@transparent属性を
追加し、それをインライン展開するよう望むこともできる。
※stringsコマンド：
ttp://www.unix.com/man-page/osx/1/strings/
わけあって、これらの機能はみなドキュメントには記載されておらず、Swift標準ライブラリの中でしか使用が許されていな
い。Swiftの表の顔ではないものの、その目的を達するために必要な機能である。特にBuiltinは、Swiftの型という高レベルの
世界とLLVM IRという低レベルの世界を結ぶ不可欠な存在だ。もしSwift標準ライブラリがその務めをしっかり果たせば、そ
れが高速化と効率化のためにどのようなテクニックを使っているかを開発者はまったく意識しないですむだろう。
0102シラクサ好き2014/11/02(日) 01:16:17.21ID:6AuyLw9a0
（2ページ目が終わったのでageさせてもらいます。）
Ars Technica
John SiracusaのOS X Yosemite レビュー
Swiftの項目
3ページ目
ttp://arstechnica.com/apple/2014/10/os-x-10-10/23/
Whither SIL?（「SLIの向かう先」）
そもそもSILがなぜ存在するのかは、一考に値する問題だ。前ページの単純な整数加算の例からは分からないが、SILでは、
SIL固有の、新しい種類の高レベル最適化が施される。それは、もともとのソースについてLLVM IRよりも多くの情報を保持
している表現形態の上でなければ不可能な最適化だ。
Swiftがジェネリックプログラミング※に対応していることを利用した、次のコードを見てほしい。
////////////////////////////////////////////////////////////
func identity<T>(x : T) -> T { return x }
func testInt() -> Int { return identity(42) }
func testDouble() -> Double { return identity(42.0) }
////////////////////////////////////////////////////////////
※ジェネリックプログラミング：
ttp://ja.wikipedia.org/wiki/ジェネリックプログラミング
（承前）
最適化を無効にすると、このコードはジェネリックなidentity()関数と、それを別個に呼び出すtestInt()関数・testDouble()関
数を含んだSILを出力※する。最適化を有効にすると、testInt()とtestDouble()は必要に応じた（そしてずっと短い）実装とな
り※、どちらもidentity()関数を全く呼ばないで済んでしまう。
※最適化されていないSILコード：
ttps://gist.github.com/siracusa/6085684045410246c513
※最適化されたSILコード：
ttps://gist.github.com/siracusa/4bf95e485948826af940
この種の最適化は、ジェネリックプログラミングをサポートする言語のコンパイラであれば当然行えるべきものだ。同時に、
これはLLVM IRではやりにくい、あるいは不可能なタイプの最適化でもある。
（承前）
LLVM IRとは違い、SILを経由する言語は現状ただ一つしかない。”Swift” Intremediate Languageという、その名称から分か
る通りだ。SILコードとSwiftコードはよく似ている。同じ名前の付いた同じライブラリをインポートするほどである。この二
者の近似性は、LLVM IRとCあるいはC++の近似性よりもずっと高い。SILはある意味高レベル仮想マシンだが（いや、その
こと※ではない。あれ※でもない）、Swift以外の言語のコンパイル先として設計されているわけではない。（JVM※やCLR※と
違い、SILはARC※の処理を露出しているのでメモリは安全ではない。）
※そのこと：
ttps://llvm.org/svn/llvm-project/hlvm/
※あれ：
ttp://www.ffconsultancy.com/ocaml/hlvm/
※JVM：
ttp://ja.wikipedia.org/wiki/Java仮想マシン
※CLR：
ttp://ja.wikipedia.org/wiki/共通言語ランタイム
※ARC：
ttp://arstechnica.com/apple/2011/07/mac-os-x-10-7/10/#arc
（ここで連投チェック入りました。無念）
（承前）
先に述べたように、AppleはSwiftの構文法が将来変更されることを明言している。（おそらくAppleは古いSwiftコードを新し
い構文に変換するツールを提供するだろう。）Swiftに固有の最適化を施しながら、Swiftの構文とLLVM IRの生成との間に余
計な結びつきを作らない方法を、SILは提供している。（Swiftよりはるかに構文の安定したCベースの言語をコンパイルする
Clang※は、抽象構文木※から直接LLVM IRを生成する）
※Clang：
ttp://arstechnica.com/apple/2009/08/mac-os-x-10-6/9/#llvm-clang
※抽象構文木：
ttp://ja.wikipedia.org/wiki/抽象構文木
SILは現時点で与えられている役割の範囲内でも目に見える利益を生んでいるが、構文に依存しない、固有のオプティマイザ
を持つ高レベルの中間形態というのは、明らかに何かのポテンシャルを秘めた技術であるように見える。もしかしたらSILに
はさらに大きな目的があり、それはまだ明らかにされていないのかもしれない。
（承前）
Frameworks integration（「フレームワークの統合」）
Swiftは全くの新言語ではあるが、Appleはこれが既存のOS XならびにiOSのフレームワークとともに機能するよう体制を整
えている。この点に関しても、”Using Swift with Cocoa and Objective-C※”という無料のe-bookが出版されている。Apple
の既存フレームワークはCとC++、そしてObjective-Cで書かれている。そしてこれらの言語はポインタを使用し、メモリに
直接アクセスする。
※Using Swift with Cocoa and Objective-C：
ttps://itunes.apple.com/us/book/using-swift-cocoa-objective/id888894773
よく練られた一連の表記慣例（と、in-out引数※などのSwiftの機能）を通じて、ほとんどのObjective-C APIはポインタ操作
なしにSwiftコードの中で直接使うことができる。多くのSwiftのデータ型も、それに相当するCocoaのデータ型と入れ替え可
能である。Xcodeは、Objective-CのコードがSwiftのライブラリにアクセスできるよう適切なヘッダファイルを自動生成す
る。Objectivc-C APIのドキュメントをSwift対応に翻訳したものまで、Appleは提供している。
※in-out引数：
ttps://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html
（承前）
しかし、慣例と翻訳では済まない面もある。低レベルのC/C++ APIに関しては特にそうだ。このレベルでの統合を可能にする
ため、何と、Swiftは一連のポインタ型の使用を通じたメモリへの直接アクセスをサポートしている。
（ポインタ型にはUnsafePointerやCOpaquePointerのように恐ろしげな名前が付けられている。適切な名称だ。）この対策
は必要な妥協であり、Swiftの他にも例えばC#のような、デフォルトでメモリの安全性が確保された言語で採用されている。
Swiftはあまりに新しく、またあまりにも秘密にされてきたので、YosemiteにはまだSwiftで書かれた大規模なフレームワーク
やアプリケーションが存在しない。しかし、Appleの構想は明らかにそれを志向している。アプリケーションであればSwiftで
書かれていてもユーザーは変化に気づかないかもしれないが、フレームワークは、Swiftの言語的慣例や機能を踏まえて推測
すれば、現在の最もモダンなObjective-Cフレームワークと比べても大きく異なった外見を呈するだろう。これこそ、将来に
向けてAppleが築こうとしている世界である。もっとも、そこへの移行には長い時間がかかるだろう。
（承前）
The shape of the future（「将来の姿」）
プログラム言語の設計とは何かといえば、開発者が目的を実現するために何をタイプするべきかを決めることだ、と考える人
がほとんどだろう。機能や意味体系、安全性、そして構文について激しい議論が戦わされるかもしれないが、その行き着く先
は一つの言語仕様である。あるいはそこまで行かないとしても、少なくとも何らかのリファレンスドキュメントは成立するだ
ろう。開発者はこれを見て判断を下す※。この言語は冗長すぎないか。意味体系は理解が難しいのではないか。妙な例外的状
況※は多すぎないか。変な文字※が多すぎないか。複雑さが自己目的化してしまっている※機能はないか。
※ある開発者の判断：
ttp://owensd.io/2014/09/24/swift-experiences.html
※例外的状況：
ttps://www.destroyallsoftware.com/talks/wat
※変な文字：
ttp://www.perl.org/
※自己目的化した複雑さ：
ttp://matt.might.net/articles/c++-template-meta-programming-with-lambda-calculus/
ネットを見て回ればこのような議論がいたるところに溢れているが、その多くはオプショナルな値※やアクセスコントロール※
など、ここでは触れさえもしなかったテーマに関するものだ。プログラム言語の構文や意味体系についてああでもないこうで
もないと論じるのは、開発者にはおなじみの心地よい暇つぶしである。また、言語の設計者が新言語を作るときにこうした問
題について検討するのも当然頷けることだ。
※オプショナルな値：
ttp://airspeedvelocity.net/2014/08/17/implicitly-converting-functions-to-return-optionals/
※アクセスコントロール：
ttp://owensd.io/2014/08/21/protected-swift.html
（承前）
Swiftの場合は、少し事情が違う。もちろん、プログラマの立場から見てObjective-Cよりも生産的で楽しいと思えるように設
計されたことは確かだ。柔軟で拡張可能でありながら、大切な安全性も確保できるように考えられている。しかし、Swiftは
コンパイラ技術者が開発したものでもある。
プログラマが何をタイプすべきかを決めることは、Swiftの設計の出発点でも到達点でもない。これは、言語の構文から始ま
ってマシン語のコードにまで達する奥行きを持った構想なのだ。Swiftが機能を採用するにあたっては、ただプログラマにど
んな経験を与えるかということだけが考えられたわけではなく、コンパイルのプロセスで何を可能にするのか、あるいは生成
するのかということも考慮されている。Swiftの開発はアカデミックな営みではない。意味論的な純粋さ、あるいは数学的な
美しさを目指しているわけではない。開発の第１日目から、Swiftは実行バイナリをどう実装するかが念頭に置かれていた言
語なのである。
このアプローチは、設計者の人間性や価値観、あるいはスキルの単なる副産物ではない。実行バイナリの実装に力点を置いた
ことは、「スクリプト言語のように楽しく表現力豊かで、同時に、低レベルのシステム開発言語のように高速で効率的である
べし」と宣言されているSwiftの使命から導かれた、当然の帰結である。
Swiftは、高レベル言語の構文と意味体系を備えた低レベル言語を作ろうという試みである。「十分に賢いコンパイラ※」の神
話に真っ向から取り組み、言語の設計プロセスの一環としてそのようなコンパイラを作り上げようと名乗りを上げている。
※十分に賢いコンパイラ (Sufficiently Smart Compiler)：
ttp://c2.com/cgi/wiki?SufficientlySmartCompiler
（承前）
Swiftの実行速度を保証する主要な手段は、静的コード解析※である。開発チームはこの技法に関して既に経験を持っている
※。変数の型の手動指定を不要にする型推論から、SILとLLVM IRの二段階で施される最適化に至るまで、Swiftのあらゆる機
能を可能にしているのは、コードを実行することなしに解析できるこのコンパイラの能力なのである。
※静的コード解析：
ttp://ja.wikipedia.org/wiki/静的コード解析
※開発チームの過去の経験：
ttp://arstechnica.com/apple/2009/08/mac-os-x-10-6/9/#static-analyzer
Builtinというモジュールを通じて、標準ライブラリの最も基本的な要素をLLVM IRのプリミティブな要素に直接ひも付けする
という手法は、Swiftとそのコンパイル環境とがいかに密接に関わっているかを示している。基本的な型をLLVM（最終的には
マシン語コード）という岩盤にネジ止めする、太く、目に見えないこれらのボルトがなければ、SwiftのパフォーマンスがCや
Objective-Cに迫ることはできなかったであろう。
ある意味で、Swiftのこの側面はC++の「コストゼロの抽象化※」の理念と似ている。異なるのは、Swiftが低レベルでのデー
タや命令のやりとりを標準ライブラリに限定し、プログラマにはそのシステムの舞台裏を開示しないという点だ。
※コストゼロの抽象化 (zero-cost abstractions)：
ttp://electronicdesign.com/dev-tools/interview-bjarne-stroustrup-discusses-c
（ここで連投規制入りました）
>>112 おお、助かる。
（承前）
バイナリの実装だけではなく、プログラマが直接関わる側面でも、Swiftはソフトウェア開発についての具体的な理念を体現
している。私はソフトウェアを書くことを職業として１８年になるので、プログラム言語の設計について自分なりの確固たる
意見を持っている。例えば、ボタンを押したらどのウィンドウが開くか、あるいはデータベースにどのデータを出し入れする
か、などといったことを制御する高レベルなコーディングをする際に、データの型に関してあれこれするコードを書くのはほ
とんど無駄な労力※だと思っている。
※無駄な労力：
ttps://sites.google.com/site/steveyegge2/is-weak-typing-strong-enough
Swiftの型推論機能はこの苦痛をある程度軽減してくれるが、Swiftの型決定が本質的には静的であるという事実は変わらな
い。型決定を静的にするか、あるいは動的にするかは、このそれぞれのアプローチがコンパイラの実装にどのような影響を与
えるかという観点だけから決まるわけではない。それは、何が「いいコード」なのかを判断する哲学的な選択眼の問題でもあ
る。おそらく、むしろこちらの方が大きいかもしれない。
そういう意図があったのかどうかはともかくとして、Swiftが私の不満を吸収してくれたのは、その設計理念が具体的な言語
仕様として結実した成果のおかげである。私はSwiftの野心的な目標に敬意を持っているし、その目標達成のため、Swiftの各
機能がそれぞれに不可欠であることも理解している。
Swiftに対する最も強い批判は、究極的にはその目標の問題だ。もし「業務に耐えるシステム開発言語」となることを諦めれ
ば、Swiftはもっと親しみやすい高レベル言語になりえたはずだ。逆に、もし単に「より良いC※」になることだけを目指して
いたなら、もっと簡潔な言語になりえただろう。Swiftが今やっていることを、たとえ試みにもせよやってみた言語はこれま
でにほとんど存在しない。難度は高く、そしてそれは自らが課す困難だ。これはつまり、まさにAppleらしい挑戦なのであ
る。
※より良いC：
ttp://golang.org （承前）
もしこれがAppleの基調講演だったら、ここでTim Cookがステージに戻ってきて、Swiftのようなものを作り出せるのは
「Appleだけだ※」と説くところである。さすがにそれは少し誇張があるかもしれないが（MicrosoftのC#※やCLR※を見
よ）、SwiftのようなプロジェクトはAppleの野望にぴったりだし、垂直的な統合を目指す社の長い伝統にも沿うものだ。
※Appleだけ：
ttp://daringfireball.net/2014/06/only_apple
※C#：
ttp://ja.wikipedia.org/wiki/C_Sharp
※CLR:
ttp://ja.wikipedia.org/wiki/共通言語ランタイム
Swiftの構想が、ソースコードから始まって最終的なマシン語コードに及ぶ、ばかりでなく、そこからさらに広がって、CPU
そのものの設計にまで達するのではないかと考えるのは、決してうがち過ぎな想像ではない。歴史をさかのぼれば、古くは
PowerPC、現在のx86、そして最近ではARMプロセッサ、それぞれに固有の特徴が、関数コールの慣習※からObjective-Cラ
ンタイムの機能※に至るまで、Appleのシステム基幹部分の効率性に影響を与えてきた。私は、コンパイラやプログラム言
語、そしてランタイムスタックと直接に結びついた機能をCPUに搭載するよう、Appleは各メーカーにロビーイングしている
（あるいは、自ら設計したチップに対しては、直接実装してしまっている）に違いないと睨んでいるし、このような動きは将
来もっと活発になるのではないかと思っている。
※関数コールの慣習：
ttps://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html#//apple_ref/doc/uid/TP40002437-SW1
※Objective-Cランタイムの機能：
ttp://www.sealiesoftware.com/blog/archive/2013/09/24/objc_explain_Non-pointer_isa.html
（承前）
一連のコンパイラツールのうち、Swiftに固有の部分は、ClangやLLVMと違ってオープソースではない。それを大々的に使う
企業が自分だけだとしても、AppleにはSwiftを確実に成功させるためのリソースと影響力がある（Objective-Cの例を見
よ）。しかしApple社内には、間違いなくSwiftをオープンソース・プロジェクトにしたい意向を持っている有力な派閥が複数
存在する。これまではとにかくYosemiteとiOS 8をリリースすることが優先事項だったようだが、今後、私はこの問題が再び
検討の対象になるのではないかと考えている。
PowerPCからIntelプロセッサへの移行以来、SwiftはAppleの開発プラットフォームにおいて最も重要な変更である。経験豊
かなObjective-Cプログラマから想定通りの反発※があったのは事実だが、Swiftは単なる変化ではない。安全性、表現性、機
能、そしておそらくパフォーマンス※※の上でさえも、飛躍的な大進歩である。しかもこれ、全てがまだリリース1.0の時点で
実現してしまったのである。
※想定通りの反発：
ttp://mjtsai.com/blog/2014/08/18/its-a-coup/
※パフォーマンス１（Swiftは速い）：
ttp://www.jessesquires.com/apples-to-apples-part-two/
※パフォーマンス２（いやそんなことはない）：
ttp://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html
Swiftはまだとても幼い。しかし前方には明るい将来が開けている。もしこれが成功すれば、サーバーサイドのプログラミン
グからインストーラスクリプト、あるいはウェブ開発に至るまで、Appleのすべての技術スタックに利益をもたらす可能性が
ある。ただ、そもそもObjective-Cの後継者としての役割がそれ自体ですでに十分価値のあるものだ。Objective-Cはこれま
でに数多くの機能拡張を果たしてきたものの、Appleの開発プラットフォームが向こう数十年にわたって安泰であるという保
証には決してならなかった。しかし、Swiftなら、Appleの今後の命運※を明るく照らしてくれるかもしれない。
※Appleの命運への危機感：
ttp://arstechnica.com/apple/2010/06/copland-2010-revisited/
0116シラクサ好き2014/11/03(月) 13:00:16.50ID:NjjIr3YV0
（やっとSwiftの項目終わったのでageます。こちらからは以上です）
（しかし「バイバイさるさん」、って腹たつわー）
乙です。
技術者でもないのにこういうの読むのが好きなので、
翻訳してくれてほんと嬉しい。ありがとう。
Siracusaさんの発音はサーキュースではなく、サーキューサ、ですね。
0119名称未設定2015/02/20(金) 00:40:23.29ID:tgawopPG0
ほ
0121名称未設定2015/05/17(日) 14:34:58.62ID:8Tcl9CIf0
それは残念
0122名称未設定2015/11/20(金) 07:17:57.28ID:ewCkF+8R0
0123名称未設定2015/12/19(土) 07:50:51.23ID:tp+Lq05u0
保守してれば、きっと誰かが。。。
0125名称未設定2015/12/22(火) 07:27:56.52ID:KImQYGYN0
和訳されないネタってのも減ってきちゃったしねえ
0126名称未設定2015/12/22(火) 13:48:58.38ID:N/D04LP/0
0127名称未設定2016/02/16(火) 16:42:33.66ID:hLayZbFU0
0128名称未設定2016/03/18(金) 22:22:19.25ID:i/WsfFOZ0
0130名称未設定2017/01/31(火) 23:47:43.49ID:pq4f/4AA0
ほ
0131名称未設定2017/02/01(水) 00:52:16.05ID:1s/x3LhZ0
捕手