オープンソース化ばんざーい！！とかそういうのは全然興味ないです、ごめんなさい。
XCode7で何気なくimport Foundationなどをすると、ついでに以下のライブラリがリンクされるそーです。
SwiftCore（Swiftのコア言語仕様）Darwin（UNIXベースのOSX/iOSの基盤部分。CoreFoundationもここに含まれる）Dispatch（Grand Central Dispatch、みんな大好きblocks）CoreGraphics（描画処理の基盤部分。今はOpenGLだと思いますがそのうち中身がMetalになるのでしょうね）ObjectiveC（Objective-Cランタイム関数）Security
Swiftがオープンソース化される、と言っても本当にpure Swiftのコンパイラだけが提供されてもあまり意味がないので、「どこまでがどうオープンソースになるのか？」というのが興味の焦点だったかと思います。
「UIKitのAPIを呼び出すだけで簡単にアプリケーションを作れるiOS開発とは別物になる」、というのはまず前提として、
Darwinの互換実装までが提供される。いまいち誰得な言語になる。Foundationまでが提供される。ObjectiveCの呪縛から逃れられない。
の2択かなーと思ってたのですが、
という意外な答えでした。
Swift自身でFoundationを記述している、というのは興味深く（普通のSwiftはObjective-CのFoundation実装を利用しているだけなので）、ここがオープンソース版との一番の違いになると思います。
Foundationの行方
を見てみると、アプリケーションフレームワークの基礎として今後もFoundationを生かしたいというようなことが書いてあります。ただ、掲げられているゴールはちょびっと変わっています。
- Make software development easier by introducing consistent conventions for things such as deallocation.
- Support Unicode strings, object persistence, and object distribution.
が、
- Make software development easier by introducing consistent conventions.
- Support internationalization and localization, to make software accessible to users around the world.
にそれぞれ変わっています。
前者はメモリ管理がARCになったことで「例えばメモリ解放のような」という喩えの意味がなくなったからでしょうか。ARCでもメモリ管理を意識しないと簡単にリークするのは変わらないので、別にそこ変えなくてもよくない？と思うのですが。
後者はNSStringはUTF16のラッパー実装でしたが、今のUnicodeコードポイントは絵文字の侵食で21bitになってたり、オブジェクトをシリアライズして永続化するという発想そのものが時代に合わなくなってきたので表現を変えた感じでしょうか。
NSUnimplemented()で検索検索っ。
なお、現在のオープンソースSwiftのFoundationは未実装な部分が多かったり、Objective-Cランタイムには存在するクラスがなかったりします。
以下のような注意書きがあります。
Important: This project is in the early stages of development. It is not yet ready for production use, but it is ready for contributions. It is scheduled to be part of the Swift 3 release.
<私訳>
重要: このプロジェクトは開発の初期段階にあります。これはまだ製品での使用はできませんが、コントリビューションの準備は整っています。Swift 3のリリースの一部として予定されています。
動的型付けを生かしたクラスクラスタの仕組みなんかは存在は抹消されるんでしょうね。SwiftにはKVCがないので、それを土台にしているKVOもありません。さらにKVOの上に乗っかってるCocoa Bindingsは時代を先取りしすぎた感じですね。
一方で、NSZoneのような無意味なだけのクラスが生き残っていますが、これは「最初の1年はFoundationの可搬性を実現することに注力し、その目標と相反するAPIのビッグバンを回避する」というような意味合いがあるみたいですね。
Foundation without Objective-C runtime
This project provides an implementation of the Foundation API for platforms where there is no Objective-C runtime. On OS X, iOS, and other Apple platforms, apps should use the Foundation that comes with the operating system. Our goal is to abstract away the exact underlying platform as much as possible.
<私訳>
このプロジェクトは、Objective-CランタイムのないプラットフォームのためのFoundation APIの実装を提供します。OSXやiOS、その他Appleのプラットフォームにおいては、アプリケーションはオペレーティングシステムに付属しているFoundationを利用するべきです。我々のゴールは、可能な限り精密な基盤となるプラットフォームを抽象化することです。
現状では、OSXでFoundationが不完全なオープンソースSwiftを使う意味はないので、XCodeで使えばいいってことですね。
これが現状だけを指すのか、Objective-Cランタイムを必要としないFoundationをオープンソースで開発し、いずれOSXやiOSもそちらに移行するのでしょうか…？
さよならNSプレフィクス
ところで、このリポジトリの文章は全部面白いので読んだほうがいいです。すでにバイナリのあるコードをビルドするより有益な情報が得られます。いくつか面白かったところを取り上げます。
API Naming and Foundation
One of the goals of the Swift 3 project is a new set of naming guidelines. The Foundation project will soon update all of its names to match the new guidelines. We will also drop the 'NS' prefix from all classes.
<私訳>
Swift 3 プロジェクトのゴールのひとつとして、命名規則の一新があります。Foundationプロジェクトはいずれ新しい命名規則と一致するように、全ての命名が更新されるでしょう。加えて、全てのクラスから'NS'プレフィクスを取り除きます。
FoundationをSwiftで再実装して、その上に載っているフレームワークも全部作り直すのでしょうかねぇ。値型のSwift Arrayと参照型のNSArrayはどういう区別になるんです？
How do we decide if something belongs in the standard library or Foundation?
In general, the dividing line should be drawn in overlapping area of what people consider the language and what people consider to be a library feature.
For example, Optional is a type provided by the standard library. However, the compiler understands the concept to provide support for things like optional-chaining syntax. The compiler also has syntax for creating Arrays and Dictionaries.
On the other hand, the compiler has no built-in support for types like NSURL. NSURL also has ties into more complex functionality like basic networking support. Therefore this type is more appropriate for Foundation.
<私訳>
どのようにして標準ライブラリまたは、Foundationのいずれに属するものだと判断すればよいですか？
一般に、言語の機能の一部だと考える人々と、ライブラリの機能であるべきだと考える人々を重ね合わせた境界で分割されるべきです。
例えば、Optionalは標準ライブラリで型として提供されています。しかしコンパイラはoptional-chaining構文などをサポートするためのコンセプトを理解しています。コンパイラはまた、配列や辞書を生成するための構文を持っています。
一方で、コンパイラはNSURLのような型は組み込みでサポートしていません。NSURLは基本的なネットワークのサポートなど、より複雑な機能との関連性を帯びます。よって、この型はFoundationの方がより相応しいです。
Swiftにおける標準ライブラリは現状に近いミニマルな構成のまま、Foundationに機能を持たせていくみたいですね。Swift 2でNSURLに関連付いたNSStringのメソッドをStringの拡張に含めるのをやめましたが、NSURLはFoundationのものだから標準ライブラリからは隔離したい、というような意図だったのでしょうか。（参照型であることを前提にしているNSPathStore2を値型のStringにキャストすることで起きるパフォーマンス劣化回避が目的だと思っていたのですが）
Why not make the existing Objective-C implementation of Foundation open source?
Foundation on Darwin is written primarily in Objective-C, and the Objective-C runtime is not part of the Swift open source project. CoreFoundation, however, is a portable C library and does not require the Objective-C runtime. It contains much of the behavior that is exposed via the Foundation API. Therefore, it is used on all platforms including Linux.
<私訳>
なぜ既存のObjective-CによるFoundation実装をオープンソースにしないのですか？
Objective-Cおよびそのランタイムで書かれたDarwinのFoundationは、Swiftのオープンソースプロジェクトには属しません。しかしながら、CoreFoundationは可搬性のあるCのライブラリであり、Objective-Cランタイムを必要としません。これにはFoundation APIを通じて公開されている振る舞いの多くが含まれています。そのため、Linuxを含む全てのプラットフォームで使われています。
「Objective-CのFoundation実装を公開すればいいじゃん？」っていう疑問は、「それはSwiftのプロジェクトとは関係ないから」という正論で一蹴していますが、Foundationを別のオープンソースプロジェクトにすればよかっただけな気もするのですよね。
Swiftのオープンソース化はそこから言語コミュニティが活発化してSwift 3へ進化することで結実するって感じなのですかねー。
そのときSwift 2.Xの資産は全てゴミになると思われますが…。