コルーチン (現時点では C++1z の最新のドラフト) が、ライブラリ拡張ではなくコア言語機能 (派手なキーワードなど) として実装されるのはなぜですか?
私が読んだことから、それらのいくつかの実装（Boost.Coroutineなど）がすでに存在し、そのうちのいくつかはプラットフォームに依存しないようにすることができます。なぜ委員会はそれをコア言語自体に組み込むことにしたのですか?
すべきではないと言っているわけではありませんが、Bjarne Stroustrup 自身がいくつかの講演で (もうどれかはわかりません)、新機能はコア言語に触れるのではなく、可能な限りライブラリに実装する必要があると述べています。
そうする正当な理由はありますか？利点は何ですか？
コルーチンのライブラリ実装がありますが、これらには特定の制限がある傾向があります。たとえば、ライブラリの実装は、コルーチンが中断されたときに、どの変数を維持する必要があるかを検出できません。たとえば、使用される変数を何らかの形式で明示的にすることで、この必要性を回避することができます。ただし、コルーチンができるだけ通常の関数のように動作する必要がある場合は、ローカル変数を定義できる必要があります。
Boost コルーチンの実装者の中で、それぞれのライブラリ インターフェイスが理想的であると考えている人はいないと思います。現在の言語で達成できる最高のものですが、全体的な使用法を改善することができます。
CppCon 2015 で、Microsoft の Gor Nishanov 氏は、C++ コルーチンは負のオーバーヘッドの抽象化になる可能性があると主張しました。彼の講演の論文はこちらです。
彼の例を見ると、コルーチンを使用する機能によってネットワーク コードの制御フローが簡素化され、コンパイラ レベルで実装すると、元のコードの 2 倍のスループットを持つ小さなコードが得られます。彼は、生成する能力は C++ 関数の機能であるべきだと主張しています。
これらは Visual Studio 2015 に初期実装されているため、ユースケースに合わせて試してみて、boost 実装と比較する方法を確認できます。ただし、Async/Yield キーワードを使用するかどうかは、まだハッシュ化しようとしているようです。そのため、標準がどこに向かうのかに注目してください。
C++ の再開可能な関数の提案はこちらで、更新はこちらで確認できます。残念ながら、それは c++17 にはなりませんでしたが、現在は技術仕様p0057r2になっています。利点としては、-fcoroutines_ts フラグを使用した clang と Visual Studio 2015 Update 2 でサポートされているようです。キーワードには co_ が付加されています。したがって、co_await、co_yield などです。
コルーチンは、golang、D、python、C# の組み込み機能であり、新しい Javascript 標準 (ECMA6) に含まれます。C++ がより効率的な実装を思いついた場合、golang の採用に取って代わるのではないかと思います。
C++1z の再開可能な関数はスタックレス コンテキスト スイッチングをサポートし、boost.coroutine(2) はスタックフル コンテキスト スイッチングを提供します。
違いは、スタックフル コンテキストの切り替えでは、コルーチン内で呼び出された関数のスタック フレームがコンテキストの一時停止時にそのまま残り、サブルーチンのスタック フレームが再開可能な関数 (C++1z) の一時停止時に削除されることです。