Visual Studio 16.10 における F# および F# ツールのアップデート

本記事は、2021 年 5 月 26 日（米国時間）ポストされた "**https://devblogs.microsoft.com/dotnet/f-and-f-tools-update-for-visual-studio-16-10/**" の意訳（と、ちょっと手を加えたもの）となります。
内容については下記原文が正となります。

https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-10-and-v16-11-preview-1-are-available-today/

-----------------

Visual Studio 16.10 にて、F# ツールのアップデートをリリースしました。今回は、2020 年 2 月の Visual Studio 16.9 のアップデートでリリースされたものをベースとして、さらなる Visual Studio における F# の開発エクスペリエンスの向上を目指しました。もちろん、今後も継続して改善を進めて行きたいと思っています。

* 外部シンボルに対する [定義へ移動] 機能をサポートしました
* 同一ソリューションにおいて C＃ プロジェクトと F＃ プロジェクトを混在させた状況に対するサポートが向上しました
* クイック フィックスとリファクタリングを強化しました
* ツールのパフォーマンスとレスポンスを向上しました
* その他、コア コンパイラを改善しました

#外部シンボルに対する [定義へ移動] 機能サポート
これは、[2016 年から機能を実装して！というリクエスト](https://github.com/dotnet/fsharp/issues/1939)をいただいていた機能でした。
その後、我々は期待に応えるべく、何度も何度も試みを続けてきました。そして…**お待たせしました。満を持して、ついに実現しました**！

それでは、以下のビデオをご覧ください。`F12` キーまたは `Ctrl +  click` を使って、まるで自分のソリューションのソースコードであるかのように、宣言に移動することができている様をご覧いただけるかと思います。やったね。

<iframe width="640" height="480" src="https://www.youtube.com/embed/56yqVkWS0BY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

宣言に移動すると、Visual Studio はシンボルが所属するモジュールや名前空間を表す完全な [F# 署名ファイル](https://docs.microsoft.com/dotnet/fsharp/language-reference/signature-files) を生成し、さらに XML ドキュメントがある場合はそれも含めて表示してくれます。
これにより、カラー化、ツール チップ ヒント、およびさらなるナビゲーションが、あたかも自分のコード ベースで署名ファイルとして宣言されているかのように機能してくれるようになりました。

※ あの時のリクエストはこちら（やりましたよ！！）

https://github.com/dotnet/fsharp/issues/1939

#C# プロジェクトと F# プロジェクトが混在されている状況のあれこれを改善しました
C# と F# のプロジェクトが同じコードベースで相互運用されている場合の最大の悩みの一つ。**それは、C# <-> F# の境界を越えて他のプロジェクトの更新を確認するためには、プロジェクトをわざわざ再構築しなければならないということ**でしょう。つらい。

でも安心してください。Visual Studio 16.10 からは、C# プロジェクトに変更を加えても、F# プロジェクトの変更を確認するためにいちいちプロジェクトを再構築する必要はなくなりました。やったね。

<iframe width="640" height="480" src="https://www.youtube.com/embed/zvuVPe11cGE" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

↑ 変更を加えてすぐ、F# プロジェクトの変更を確認できますよ！

しかし、残念ながら 2021 年 5 月現在、その逆はまだできていません。C# <-> F# の interop 境界をツールの観点ですべて対応ができているとは言えません。まだまだやるべきことがあります。
現在の状況をまとめると、以下のようになります。

##### できること
✔️ F# プロジェクトの変更は、C# プロジェクトをわざわざ再構築せずに「見る」ことができます（上記動画）
✔️ F# から C# のシンボルの定義に移動して、C# コードベースの宣言箇所に移動することができます。

##### まだできないこと
❌ C# プロジェクトからは、F# プロジェクトの変更を再構築せずして「見る」ことはできません。
❌ C# から任意の F# のシンボル定義に移動し、F# コードベースの宣言箇所にナビゲートすることはできません。

遺憾ながらまだできていないことはあるのですが、これらをすべて「できること」にせしめるために、我々は鋭意対応作業を進めています。なお、この作業は非常に低レベルのレイヤーに及ぶもので、なんと F# コンパイラの変更だけではなく、おそらく C# 側のツールの変更も含まれることになる見込みです。超がんばる。

#XML ドキュメントのスキャフォールディング
Visual Studio 2019 リリース時に、パフォーマンスへの懸念から、ソース内の XML ドキュメントをスキャフォールドできる機能を無効にしました。この実装は、UI の遅延の大きな原因となり、特に大量のメモリ消費と組み合わされた場合、Visual Studio の全体な動作に悪影響を及ぼす可能性があることが判明しました。

Visual Studio 2019 では、F# ツールのパフォーマンスを大きく向上させ、UI の遅延に影響を与えないよう、XML ドキュメントのスキャフォールディングの実装を変更しました。この変更に伴い、現在は機能を有効にしています。

<iframe width="640" height="480" src="https://www.youtube.com/embed/oNXSfoBeEnw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

#クイックフィックスとリファクタリングの追加
前回のリリース同様、Visual Studio 16.10 のリリースでは、クイックフィックスとリファクタリングを追加しています。

###未使用のバインディングを削除するクイック フィックス
任意のスコープで使用されていないバインディングがある場合、削除可能と判断された場合、削除したほうがよいでしょう。

![vsc](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2021/05/fsharp-1.png)

###適切な不等号演算子のクイックフィックス
他の言語を使っている方や、F# 初心者の方の中には、`!=` を使って、エラーが出て混乱してしまう方もいるかもしれません。このクイックフィックスでは、不等号の演算子として `<>` を使うように修正してくれます。

![vsc2](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2021/05/fsharp-2.png)

###型が不確定なオブジェクトに型の注釈を追加するクイック フィックス
F# コンパイラは、技術的にはコードがコンパイルされないのに、F# ツールはコンパイラができない型を実際に推論するという、なんとも紛らわしいエラーを出すことがあります。このクイック フィックスは、その既知の型を提案してくれるようになります。

![vsc3](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2021/05/fsharp-3.png)

###型アノテーションのリファクタリングを追加
最後に、Visual Studio 用の F# ツールに最初のリファクタリングを追加しました。リファクタリングはクイック フィックスとは異なり、警告やエラー起点で作動するものではありません。
カーソル位置でコードのリファクタリングが利用可能であることを示す LightBulb（電球アイコン的なもの。その横にはエラーアイコンはありません）が表示される形で動作します。

![vsc4](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2021/05/fsharp-4.png)

#ツールのパフォーマンスとレスポンスがさらに向上
これまでの Visual Studio のリリースと同様に、大規模なコードベースに対するツールのパフォーマンスとレスポンスの向上に引き続き取り組んでおります！

###メモリ使用量の削減
大規模ソリューションのメモリの使用量、がんばりました。
Visual Studio が開いているドキュメント内のコンストラクトに色を付けるのは、実際には「分類」と呼ばれるプロセスの結果です。分類は2つのパスで実行されます。

1. シンタックス分類
2. セマンティック分類

まず、シンタックス分類では、キーワードと非キーワードの識別などができます。型チェックを必要としないため、非常に動作が軽いです。非常に大きなファイルでは、型が色づけされる前にキーワードが色づけされてることにお気づきになるかとおもいます。

セマンティック分類は、クラス、構造体、enum 型、メソッド、プロパティなどを区別するような作業で、動作はコストが高いものになります。結果として、ドキュメントの中でよりニュアンスを利かせた色づけを行います。
しかし、セマンティック分類は通常、言語サービスで最初に実行されるセマンティック操作であるため、キャッシュもいっぱいになってしまいます。

セマンティック分類で使用されるキャッシュの 1 つは、実分類情報そのものであり、以前はまるっと 1 つの大きな配列として格納されていました。しかし、これでは、時間が経つにつれ、かなりのRAM を消費してしまう可能性があります（特に、大きなドキュメントをたくさん開いている場合は顕著かと…）。
そこで、われわれは Visual Studio 用の F# ツールに対し、[メモリ マップト ファイル](https://docs.microsoft.com/ja-jp/dotnet/standard/io/memory-mapped-files)を用いてデータをバックアップするように、他のいくつかの大規模なデータストアに対してアプローチしました。
これにより、Visual Studio セッションで開いているファイルの数に応じて、F# コードベースで最大 200MB の節約が可能になりました。やったね。

この変更は [Saurav Tiwary](https://github.com/dr0pdb) さんによって提供されました。Sauravさん、キラリと光る素敵な内容ありがとうございます！

https://github.com/dr0pdb

#より多くの IDE 機能のレスポンスが向上しました
前回のリリースでは、F# 言語サービスにおいて、セマンティック情報のリクエストを[シリアル化しない](http://%28https//devblogs.microsoft.com/dotnet/f-and-f-tools-update-for-visual-studio-16-9/#improved-responsiveness-for-most-ide-features)ようにするための作業を開始しました。ちょっとおさらいしますと、型チェック動作は、ダウンストリームに影響を与える可能性があるため、関連するしくみは、セマンティック情報を必要とするリクエストをシリアル化し、リクエストをキューイングして順番に処理していきます。
ただ、実際のところは、この方法が必要になることはめったにありません。そのため、今回のリリースでは、キューからさらに多くのオペレーションを減らすことにしました。

まあいろいろ書いていますが、要はこうした変更によって、入力レスポンスが以前よりも早くなっていることを実感いただけると思います。特に、大規模なコード ベースにおけるツール機能だと、おお！速いぞ！と思っていただけるのではないでしょうか。やったね。

https://devblogs.microsoft.com/dotnet/f-and-f-tools-update-for-visual-studio-16-9/#improved-responsiveness-for-most-ide-features

#コア コンパイラの改善
最後に、コンパイラの改善点をいくつか紹介いたします。

###プロジェクト ファイルにおける WarnOn のサポート
本リリース以前は、特定のコンパイラ コードに対する警告を導入したい場合、プロジェクト ファイルの `OtherFlags` プロパティで `--warnon:number` を使用しなければなりませんでした。

そこで、今回のリリースでは、C# のように `WarnOn` を使用し、数値をダイレクトに渡すことができるようになりました。

これは [Chet Husk](https://github.com/baronfel) 氏によって実装されました。Chetさん、ありがとうございます。最高にクールですね。手前の WatchDog がキュートにキマってますね。

https://github.com/baronfel

###プロジェクトファイルでの ApplicationIcon のサポート
えー、本リリース以前は、F# のプロジェクトファイルで `ApplicationIcon` を設定しても「しかし、なにもおこらなかった！」でした。ええ。

今回のリリースでは、C# と同様に、プロジェクト ファイルにこのプロパティをちゃんと設定できるようになりました。また、コンパイラ フラグとして `--win32icon` が追加されました。

これは [albert-du](https://github.com/albert-du) さんによって実装されました。もうほんと尊いです。ありがとうございました。

https://github.com/albert-du

#その他の Span 最適化
[Jérémie Chassaing](https://github.com/thinkbeforecoding) さんは、`Span`/`ReadOnlySpan` をループするために、かなりイカした最適化を実装してくださいました。クール。

https://github.com/thinkbeforecoding

以下の F# コードです。

```diff_f_sharp
let sumArray (vs: int ReadOnlySpan) =
    let mutable sum = 0
    for i in 0 .. vs.Length-1 do
        sum <- sum + vs.[i]
    sum
```

境界チェックを取り除いたクリーンな IL (※ 訳注 : 中間言語 = intermediate language = IL) を出力するようになり、ランタイムがループをよりアグレッシブに最適化できるようになりました。この最適化は、`for x in xs do` ループにも適用されます。

#今後の展開
今回のリリースでは、以下の 3 つの取り組みをサポートするために、正式にギアチェンジを行います。

1. .NET 6でのF#のサポート強化
2. .NET InteractiveでのF#のサポート強化
3. Visual Studio 2022 での F# のサポート強化

まず最初のイニシアチブでは、近日リリースする予定の言語機能をfix するつもりです。今回は、多くの言語機能を追加するつもりはありません。今は、コア コンパイラや中心となるツール（F# インタラクティブ、Visual Studio）の改善の方が、優先して取り組む価値があると考えているためです。.NET 6 は [LTS リリース](https://github.com/dotnet/core/blob/main/release-notes/6.0/README.md)なので、既存の機能の完成度、パフォーマンス、信頼性を優先しています。それは必ずしも機能の凍結を意味するものではありません。実際、特にビルド時間の改善に関連して、「コンパイラ機能」を 1 つまたは 2 つリリースすることになるかもしれませんが、これは　F# 5 と比較して、新しい言語機能のセットが小さくなることを意味します。

.NET 6 に盛り込まれる言語変更の最終的な内容が決まりましたら、その内容とリリースに割り当てるバージョン番号を発表します。楽しみにしていてください。

https://github.com/dotnet/core/blob/main/release-notes/6.0/README.md

次に、2 つめのイニシアチブですが、F# コードが優れた出力（プレーン テキスト、チャート）を提供し、優れたツール（インテリセンス、ツールチップ）を備え、幅広いライブラリ（特にデータ　サイエンスや機械学習向けのもの）を使用して、すこぶる開発が捗るようにすることに主眼を置いています。特に、ネイティブな依存関係にあるさまざまなパッケージを取り込むための、ちょっと変わった、それでいて魅力的なパッケージ レイアウトをサポートしています。
しかし、ツール体験（補完やツールチップなど）がすべてうまく機能するようにするなど、わたしたちがやるべきことはまだあります。GA で .NET インタラクティブがリリースされた暁には、心躍るクールな素晴らしい F# 体験を提供することを約束します。

最後に、私たちは今後リリースを控えている Visual Studio 2022 で素晴らしい F# 体験を提供できるよう、超気合をいれてすすめています。2022 年の Visual Studio 自身のプロセスが 64 bit 対応になる予定なので、現在と比べて Visual Studio 自体が利用できるメモリ上限値が大幅に向上するため (※訳注 : これまでは Visual Studio は 32bit プロセスだったので、仮想メモリ空間がユーザーモード 2GB しかなく、その中で処理をやりくりする必要があった。たいへん。）必然的に Visual Studio 自体がメモリをたくさん使うようになります。そのため、私たちはパフォーマンスの分析を、多くの時間を費やし注意深くすすめています。Preliminary ビルドでは、F# コード ベースをロードして [すべての参照を検索] のような、ヘビーな処理を実行すると、メモリ使用量が約 2 倍になることがわかっています。こうしたことについて、われわれは要因を可能な限り低減することに取り組んでいるのです。そしてさらに、Visual Studio の生産性向上のための機能を強化し、Inline Hint、C# との連携強化、ビルド時間の短縮などの機能も提供していきたいと考えています。

そんなわけで、今後の F# および Visual Studio について、乞うご期待です。F# のプログラミング、エンジョイしてくださいね！F# 最高。

-------------------

以上、[フィリップ](https://devblogs.microsoft.com/dotnet/author/phcartmicrosoft-com/)さんからでした。
![phil](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2018/10/Phillip-Carter-150x150.png)
それではみなさんごきげんよう。
F# 超楽しいですよ！！