2017年にThe .NET Language Strategyが公開されて以来、.NETコミュニティの共通的な認識は、Visual Basicは事実上、寿命の尽きた言語である、というものだった。これには多くの理由があった。取り上げれば、それだけでひとつの記事になる。今回の記事では、VBがMicrosoftによるサポートを受け続けている点に注目する。
Visual Basic 16.9の言語仕様
最初に取り上げるVB 16.9の機能は、デフォルトインターフェースメソッドのサポートだ。これは、インターフェースに実装付きメソッドを追加することができるという、非常に物議を醸したC# 8の機能である。これは事実上、interfaceというキーワードに、抽象的なインターフェースよりも抽象クラスに近い振る舞いをさせるものだ。
今回の変更では、Visual Basicでデフォルトインターフェースメソッドを新たに作ることはできないが、利用することは可能になる。この変更は、.NET Core/.NET 5以降のライブラリとの相互運用シナリオをサポートする上で必要だと考えられる。
次に紹介する機能は、ソースジェネレータのサポートだ。この機能については、"C#開発者がユーザコードを検査し、新たなC#ソースファイルを生成してコンパイルに加えることの可能なコンパイラ機能"である、と説明されている。C#およびVBのコンパイルプロセスへのコードインジェクションを可能にするという目標は、その起源をRoslynの初期にまでさかのぼる。
VB 16.9のもうひとつの機能は、資料には単に"init-onlyプロパティの参照が可能"になる、と記されたものだ。これもまた、言語機能の拡張というよりも、相互運用性に注目したものと言えるだろう。
Windows Formsのサポート
.NET CoreのVisual Basicに対する共通的な不満は、Windows Formsデザイナの出来がよくないことだった。MicrosoftのKlaus氏は、これについて、理由の大部分はVBのイベント構文がC#のものと大きく違う点にある、と説明している。
Visual Basicでは、宣言的なイベント構文を使用するのが通例になっている。フィールドの割り当て時に、イベントハンドラを自動的にアタッチおよびデタッチする必要があることを示すキーワードとして、WithEventが使用される。その上で、メソッドがイベントを受信することを示すためにHandlesキーワードを使用するのだ。このスタイルは結果として、C#の使用する命令的スタイルとは大きく異なったコードパターンになるため、デザイナには付加的な処理が必要になる。
Klaus氏とKathleen Dollard氏によると、デザイナがVBの宣言的スタイルを使って正しく動作するようになる。
アプリケーションフレームワーク
VBに固有の機能のひとつに、"Myネームスペース"機能セットの一部である、Application Frameworkがある。Application Frameworkは、ユーザ設定の管理、アプリケーションインスタンスの複数同時実行の防止、認証モードの設定といった、グラフィックアプリケーションのための機能を提供する。
10年以上前にはこのApplication Frameworkが、多くの開発者がWindows FormsプロジェクトでC#よりもVBを最初に選択するおもな理由になっていた。そのため、.NET Coreでこれが使用できないことは、マイグレーションパスの大きな障害と見られていたのだ。
VB 16.9では、Application Frameworkが拡張されて、高DPIのシナリオを管理するイベントが追加されている。