マイクロソフト、JavaScriptに型宣言を追加しつつトランスパイラ不要の「Types as Comments」をJavaScript仕様策定会議のTC39に提案へ

2022年3月11日

マイクロソフトのTypeScript開発チームは、JavaScriptのコードにTypeScript互換のアノテーション（注釈）を加えることで変数や関数などの型を宣言し、エディタなどのツールで型情報を活用可能にする一方、実行時にはJavaScriptエンジンがアノテーションを無視することでコードをトランスパイラで変換することなく実行可能なJavaScriptの新構文「Types as Comments」を、JavaScriptの使用を策定する「TC39」（Ecma International, Technical Committee 39）に提出する計画を明らかにしました。

このマイクロソフトの発表には、TC39の共同議長であるRob Palmer氏やJavaScriptの生みの親であるBrendan Eich氏、Denoらが好意的なツイートを寄せています。

This proposal aims to improve the developer experience by making it even easier to use types in JavaScript.https://t.co/J3v9IEWbOJ
— Rob Palmer (@robpalmer2) March 9, 2022

I've been saying it'll take time (@Hixie: "Things that are impossible just take longer"), but it looks like "Types as Comments" is coming to ECMA-262, thanks to Microsoft, Bloomberg, Igalia, and many others on TC39. This is great news! https://t.co/HJalcNxgri
— BrendanEich (@BrendanEich) March 9, 2022

Great that the covers are finally lifted off this proposal!

We're excited to bring in our extensive experience with running TypeScript without a build step at @TC39. https://t.co/ok6mjuAcKg
— Deno (@deno_land) March 9, 2022

型宣言はほしいが、トランスパイラは面倒だし冗長なコメントもイヤ

JavaScriptのように変数の型を宣言せずに文字列や数字を自由に代入して演算できるプログラミング言語は、一般にタイピング量が少なく、気軽で迅速にプログラミングできる利点があります。

しかし間違った値を代入したり、本来なら演算するべきでない変数同士を演算させてもエラーにならずバグの原因に気づきにくいため、大規模なアプリケーションの開発では変数や型を宣言できるプログラミング言語が望ましいと考えられています。

そこでJavaScriptを用いた大規模開発では、JavaScriptの構文を拡張して型宣言などを可能にした、TypeScriptに代表されるいわゆるAltScriptによってプログラミングを行うことがよく行われています。

ただしTypeScriptなどのコードは、そのままではWebブラウザやNode.jsなどのJavaScriptエンジンでは解釈できずエラーになるため、実行前にトランスパイラと呼ばれる変換プログラムによってJavaScriptに変換する作業が必要になります。

トランスパイラの手間を省くためにJavaScriptのコメントとして型情報を記述する方法なども存在しますが、この場合はコメントが冗長になり、コードをメンテナンスする手間もかかるという見方があります。

トランスパイラなどを使わずそのまま実行できて、しかも簡潔に型宣言を記述できる何らかの記述方法が望ましい、と考えられるわけです。

実行時には無視されるアノテーションをJavaScriptに追加

今回マイクロソフトが提案した「Types as Comments」は、JavaScriptのコメントではなくコード中にアノテーションとしてTypeScript互換の型宣言を簡潔に記述します。下記がその例です。

let x: string;

アノテーションは「：」で始まり、そのあとに型を記述します。ここでは変数xがstring（文字列）型として宣言されています。これによりTypeScript対応ツールなどでは型情報を活用した機能を提供できます。

この例の後に、次のようなコードが続くとします。

x = "hello";
x = 100;

型の情報を活用するツールでは「x=100;」は文字列型に対して数値を代入しようとしているため、間違った代入としてエラーを表示します。一方でこれをJavaScriptエンジンで実行すると、型情報は無視されそのままエラーにならず実行されることになります。

このようにエディタなどのツールでは型情報を活用しつつ、そのまま実行できるこの提案の利点を、マイクロソフトはブログ「A Proposal For Type Syntax in JavaScript」で次のように説明しています。

A developer could get instant type-checking feedback in an editor with TypeScript support, run TypeScript on the command line, and add TypeScript as part of their CI tasks. The biggest difference is that because we would not need a build step, we would dramatically lower the barrier to entry for JavaScript devs to experience the power of types and great tooling.

開発者はTypeScriptをサポートしたエディタで即座に型チェックのフィードバックを得ることができ、コマンドラインでTypeScriptを実行し、CIタスクの一部としてTypeScriptを利用できる。最大の違いは、ビルドする必要がないため、JavaScript開発者が型と優れたツールの能力を体験するための参入障壁が劇的に低くなることだ。

そして、あくまでもJavaScript実行時には型宣言は無視されることを強調しています。

Our team isn’t proposing putting TypeScript’s type-checking in every browser and JavaScript runtime – nor are we proposing any new type-checker to be put in the browser. We think doing that would cause problems for JavaScript and TypeScript users alike due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of halting innovation in the type-checking space.

私たちのチームは、TypeScriptの型チェックをすべてのブラウザとJavaScriptランタイムに入れることを提案しているわけではないし、ブラウザに新しい型チェッカーを入れることを提案しているわけでもない。それはランタイムの性能や既存のTypeScriptコードとの互換性の問題、そして型チェックの分野でのイノベーションを止めてしまうリスクなど、JavaScriptとTypeScriptのユーザーにさまざまな問題を引き起こすものと考えている。