欠落している大きな部分は、パイプラインにフックされていることです。そうでなければ、提供されたものよりもはるかに進んでいません.Emit
。誤解しないでください。Roslyn は多くの優れた機能をもたらしますが、プリプロセッサとメタ プログラミングを実装したいと考えている私たちにとっては、現時点では予定されていなかったようです。「コード提案」または「問題」/「アクション」と呼ばれるものを拡張機能として実装できますが、これは基本的に提案されたインライン置換として機能するコードの 1 回限りの変換であり、新しい言語を実装する方法ではありません。特徴。これは、拡張機能を使用して常に実行できることですが、Roslyn を使用すると、コードの分析/変換が非常に簡単になります。
Codeplex フォーラムで Roslyn 開発者から寄せられたコメントを読んだ限りでは、パイプラインにフックを提供することは当初の目標ではありませんでした。彼らが C# 6 プレビューで提供したすべての新しい C# 言語機能には、Roslyn 自体の変更が含まれていました。したがって、本質的に Roslyn をフォークする必要があります。Roslyn をビルドして Visual Studio でテストする方法に関するドキュメントがあります。これは、Roslyn を fork して Visual Studio に使用させるには、手荒な方法です。あなたの新しい言語機能を使用したい人は誰でもデフォルトのコンパイラをあなたのものに置き換えなければならないので、私は強引だと言います. これが乱雑になり始める場所を見ることができました。
Roslyn をビルドし、Visual Studio 2015 Preview のコンパイラを独自のビルドに置き換える
もう 1 つの方法は、Roslyn のプロキシとして機能するコンパイラを構築することです。VS が活用できるコンパイラを構築するための標準 API があります。しかし、それは簡単な作業ではありません。コード ファイルを読み取り、Roslyn API を呼び出して構文ツリーを変換し、結果を出力します。
プロキシ アプローチのもう 1 つの課題は、実装する新しい言語機能を IntelliSense で適切に動作させることです。おそらく、C# の "新しい" バリアントを用意し、別のファイル拡張子を使用し、IntelliSense が機能するために Visual Studio が必要とするすべての API を実装する必要があります。
最後に、C# のエコシステムと、拡張可能なコンパイラが意味するものについて考えてみましょう。Roslyn がこれらのフックをサポートしていて、Nuget パッケージまたは VS 拡張機能を提供して新しい言語機能をサポートするのと同じくらい簡単だったとしましょう。新しい Do-Until 機能を利用する C# はすべて、本質的に無効な C# であり、カスタム拡張機能を使用しないとコンパイルできません。この道を十分に進んで新機能を実装する十分な人数がいると、互換性のない言語機能がすぐに見つかります。誰かがプリプロセッサ マクロ構文を実装している可能性がありますが、他の誰かの新しい構文と一緒に使用することはできません。なぜなら、彼らはたまたま同様の構文を使用してマクロの開始を描写していたからです。多くのオープンソース プロジェクトを利用していて、そのコードを掘り下げていることに気付いた場合は、プロジェクトが利用している特定の言語拡張機能を脇道に置いて調査する必要がある多くの奇妙な構文に遭遇するでしょう。これ狂気かもしれません。私は言語機能について多くのアイデアを持っており、これに非常に興味を持っているので、否定論者のように聞こえるつもりはありませんが、これが意味することと、それがどれほど保守可能かを考慮する必要があります。どこかで働くために雇われ、あなたが学ばなければならないあらゆる種類の新しい構文が実装されていて、それらの機能が C# の機能と同じように精査されていなければ、それらのいくつかが適切に設計/実装されていないことは間違いありません。 .