never型とプロパティアクセス
TypeScriptにはneverという型があります。先日も記事にしましたが、簡単に言うとこれは「値を持たない型」です。
never型は、あらゆる型に対してその部分型として振る舞います。例えば、never
が number
の部分型であることは次のコードでわかります:
TypeScriptにはneverという型があります。先日も記事にしましたが、簡単に言うとこれは「値を持たない型」です。
never型は、あらゆる型に対してその部分型として振る舞います。例えば、never
が number
の部分型であることは次のコードでわかります:
TypeScriptをはじめとするいくつかのプログラミング言語には、never型という型がある。この型は典型的には「制御を返さない関数」の返り値として使われる:
function f(x: string): never {
console.error(x);
throw new Error();
}
never型は型システム的には「値を持たない型」「任意の型の部分型」として特徴づけられる。
他のプログラミング言語、例えば私が作っているLunarMLにもnever型があると便利だろうか?
続きを読むこの記事は TypeScript Advent Calendar 2023 の8日目の記事です。言語実装勢にも役立つ内容を含んでいるかもしれないので、 言語実装 Advent Calendar 2023 にも登録しています。
TypeScriptで型システムに興味を持った人が「型システム入門」を読んだという話を時々聞きます。「型システム入門」は、Types and Programming Languages (TAPL) という本の邦訳で、型システムに興味を持った人が読むのは自然なことです。
ですが、この本の原著は2002年出版で、最近の話題がカバーされていなかったり、邦題に「入門」とあるように発展的な話題は扱っていなかったりします。一応続編的な感じのAdvanced Topics in Types and Programming Languages (ATTAPL) という本はありますが、これも2004年なので最近の話題はカバーされていません。
そして、TypeScriptの型システムは最近の型の理論/技術をちょいちょい使っています。
そういうわけで、私としては、TypeScriptで型システムに興味を持った人が辿り着くのが「型システム入門」止まりで本当に良いのか、という気持ちがあります。「型システム入門」の先を見たくはありませんか?
残念ながら私は型理論の専門家ではなく、高度な型システムの理論的な説明はとても書けません。なので、この記事ではTypeScriptの型システムのいくつかの側面を紹介し、文献へのポインターを提示することにします。
なお、私はTypeScriptの実装は読んでいません。あくまでドキュメントや挙動を見て判断しています。
続きを読むTypeScript で作っていたプロジェクトに、後付けで PureScript を追加しようとしたらかなり辛かった。
(わざわざ言語を混在させたい理由としては、型クラスや演算子オーバーロードを使いたい&既存のコードを全部書き直す暇はない、が挙げられる)
辛い理由としてはそもそもモジュールとバンドラーの周辺がまだ成熟していないというのもあるだろうが、 TypeScript 固有の理由として、 TypeScript コードから PureScript モジュールを読み込むための型定義が足りないという問題がある。
Stack Overflow を見ると、同じことで悩んでいる人がいた:
しかし、どの解決策もイマイチである。
コンパイル済みの PureScript を使うだけなら --allowJs
オプションという手もあるだろうが、せっかく型がある言語で書いたのだから、適切な型チェックがされて欲しい。PureScript のコンパイル時に TypeScript 用の型定義ファイル .d.ts
を出力させるようにはできないのか?
PureScript の GitHub Issues にも「.d.ts を生成させたい!」というトピックがあるが、特に動きがあるようには見えない。
コンパイラーにそういう機能がないならば、自分で作ってしまおう!ということで、作った。
前にこのブログの記事に書いたように、TypeScript 1.4以降(ターゲットがES5の場合は1.5以降)では let/const による変数宣言ができるようになった。let は書き換え可能な変数で、const は書き換え不可能な変数だ。let 宣言と const 宣言の登場によって、var 宣言は用済みになったと言っていいだろう。
let も const もスコープに関する規則は同じなので、書き換えない変数に対して let と const のどちらを使っても違いはないはず。そう思って、個人的に書いているコードでは文字数を重視して常に let の方を使っていた。
しかし、 TypeScript 2.0 で導入された control flow based type analysis により、「書き換えない変数に対して let と const のどちらを使っても違いはない」とは言ってられなくなった。 続きを読む
ECMAScriptの変数のスコープが不思議な挙動をするのはよく知られた話だ。ECMAScript 5での変数のスコープは以下のいずれかに大別される(はず)。ブロックスコープがない。
普通に使う変数が関数スコープしかないのは不便、ということで、MozillaはJavaScript 1.7(2006年頃)でlet文を導入した。が、しかし、他のブラウザには普及せず、Mozillaの独自拡張に留まることになった。
時は過ぎ、ECMAScript 5が制定され、次はECMAScript 6という流れになってきた。そして、ECMAScript 6にはlet文が導入されることになった(MozillaがJavaScript 1.7で導入したものとは微妙に仕様が違う)。めでたしめでたし。
ECMAScriptに静的型を付けたTypeScriptは、当初はlet文をサポートしていなかった。それが、TypeScript 1.4で、ECMAScript 6へコンパイルする場合のみlet文をサポートするようになった。
が、ECMAScript 6(のlet文)に対応していないブラウザはまだまだたくさんある(今調べてみたら、IE11ではES6のlet文に対応しているけど、Safariでは対応していないようだ)。できれば、TypeScriptのようなaltJS言語でlet文を使いつつ、コンパイル後のJavaScriptでは従来のvarを使ってほしい。
が、let文を従来のJavaScript (ECMAScript 5)に変換するのはそう自明なことではない。特に問題になるのは、ループ内の変数を、ループの外に持ち出される関数で使っている場合だ。[code lang=”js”]
var a = [];
for (var i = 0; i < 5; ++i) {
let x = i * i;
a.push(function() { return x; });
}
[/code]上のコードを下のように単純にvarを使うと挙動が変わってしまう。[code lang=”js”]
var a = [];
for (var i = 0; i < 5; ++i) {
var x = i * i;
a.push(function() { return x; });
}
[/code]このコードを正しくECMAScript 5に翻訳するには、即時実行関数(IIFE)を使って以下のようにしなければならない。[code lang=”js”]
var a = [];
for (var i = 0; i < 5; ++i) {
(function() {
var x = i * i;
a.push(function() { return x; });
}());
}
[/code]こういう非自明、というかパフォーマンスに影響するところがあるので、TypeScript 1.4ではES5へのコンパイル時にlet文がサポートされなかったのだろう。
が、しかし、TypeScript 1.5ではES5へコンパイルする場合でもlet文が部分的にサポートされるようになるようだ。「部分的に」というのは、ループが絡まない、変数のスコープのチェックと名前の変更で済む場合、のようだ。[code lang=”js”]
{
let x = 123;
console.log(x); // OK
}
console.log(x); // エラー
[/code]
ループが絡む、IIFEを使った変換が必要な場合は、
test2.ts(2,1): error TS4091: Loop contains block-scoped variable 'x' referenced by a function in the loop. This is only supported in ECMAScript 6 or higher.
というエラーが出た。
[code lang=”js”]
let a: Array<() => number> = []
for (var i = 0; i < 5; ++i) {
let x = i*i;
a.push(() => x);
}
a.forEach(console.log);
[/code]
GitHubでの該当するIssue/Pull Requestは以下のようだ。
let文のサポートとしては不完全とはいえ、varの関数スコープのせいで意図しない同名の変数を参照していた〜〜みたいな事故は防げると思われるので、積極的に使っていきたい。
【2017年12月18日 追記】この記事は古いTypeScript (2.0以前) を念頭に置いている。もちろん、現在のTypeScriptにも当てはまる記事はあるだろうし、TypeScript以外の言語における合併型 (union types) についてもある程度読み替えられるかもしれない。ただしElmとは “Union Types” の用法が完全に相入れないのでElmユーザーの方はお帰りください。
TypeScript 1.4について、 TypeScript 1.4.1 変更点 – Qiita という記事が目に留まった。で、その中の
直和型(Union Types)
という項目に引っかかりを感じた。:
なぜ引っかかりを感じたかというと、TypeScriptに今回導入されたUnion Typesと、巷に言う直和型というのは、異なる概念であるからだ。
注意:以下の話は型理論の専門家でもないフツーの学生が適当に書いた程度の信憑性しかありません。
TypeScript 1.4がリリースされた。目玉機能としては Union Types とか ECMAScript 6 出力モードの搭載とかになるのだろうが、他にもいろいろ地味だが嬉しい機能追加などがあるようだった。
前にTypeScriptで組み込みオブジェクトを拡張できないというようなことを書いたが、そのとき感じた問題点が直っている。具体的には以下。
interface ほにゃららConstructor
というものに変更されている。よって、各種組み込みオブジェクトのコンストラクタに勝手なプロパティーを追加できる。あと地味に便利だと思ったのはコンパイラ tsc
に追加された --noEmitOnError
というオプションである。今まではソースコードが解釈さえできれば型チェックが通らなくても ECMAScript の出力が生成(!)されていて、Makefile で TypeScript のコードをコンパイルする時に不便だった。だが、このオプションがあれば型チェックが通ったコードしか出力されないので、Makefile との相性が上がる。
最近、自分で書くWebアプリ、ブラウザアプリには、JavaScriptの代替言語としてTypeScriptを使っている。
TypeScriptの気に入っている点は、
あたりである。逆に、不満があるとすれば
あたりであろうか。まあ不満があったら他のaltJSを使えばいい話だが。
[2015年1月18日 追記] 以下の内容はTypeScript 1.4のリリースに伴い古くなりました。詳しくはこちら。
ECMAScript 6で導入されるライブラリ関数は、一部は型宣言を書いてやることでTypeScriptからも使えるようになる。例えば、前の記事で Math.hypot
や Math.sinh
などの関数に触れたが、それらは[sourcecode lang=”js”]
interface Math {
hypot(…values: number[]): number;
sinh(x: number): number;
}
[/sourcecode]のような宣言を書いておけば、コンパイルが通るようになる。まだこれらの関数を実装していないブラウザ用に、polyfill(shim)も書いておくか、読み込むといいだろう。
このほか、例えば、Array.prototype.find
の型宣言は[sourcecode lang=”js”]
interface Array<T> {
find(callback: (element: T, index: number, array: T[]) => boolean, thisArg?: any): T;
}
[/sourcecode]というふうにできる。
ここまではいい。
JavaScriptのイディオムとして、配列ライクなオブジェクトを変換するのに、Array.prototype.slice
が使われる。もちろんこのイディオムはTypeScriptでも使えるが、Array.prototype
の型は Array<any>
となっているので、要素の型に対する型チェックや型推論が働いてくれない。幸い、ECMAScript 6では、Array.from
という関数が導入される予定なので、こいつの型を[sourcecode lang=”js”]
from<T>(arrayLike: {[n: number]: T; length: number}): T[];
[/sourcecode]のように宣言してやれば型推論とかが効いて便利なはずだ。
だがしかし。組み込みの Array
オブジェクトの型は標準の lib.d.ts
において[sourcecode lang=”js”]
declare var Array: {
new (arrayLength?: number): any[];
…
prototype: Array<any>;
}
[/sourcecode]のように宣言されている。こいつに from
メソッドを追加しようとして自分のコードで[sourcecode lang=”js”]
declare var Array: {
from<T>(arrayLike: {[n: number]: T; length: number}): T[];
}
[/sourcecode]と書くとエラーが出る。既存のメソッドも書かないとダメかと思って[sourcecode lang=”js”]
declare var Array: {
new (arrayLength?: number): any[];
…
prototype: Array<any>;
from<T>(arrayLike: {[n: number]: T; length: number}): T[];
}
[/sourcecode]と書いてもエラーになる。モジュールならばどうかと思って[sourcecode lang=”js”]
module Array {
from<T>(arrayLike: {[n: number]: T; length: number}): T[];
}
[/sourcecode]と書いてもエラーになる。組み込みの Array
オブジェクトの型は lib.d.ts
で書かれたものから変更できないのだ。
だがちょっと待て。Math
オブジェクトは自前で拡張できたではないか。これは何でだったかというと、Math
オブジェクトは[sourcecode lang=”js”]
interface Math {
…
}
declare var Math: Math;
[/sourcecode]という風に定義されていて、Math
インターフェースにメソッドを追加すれば Math
オブジェクトを拡張できたのだ。Array
も[sourcecode lang=”js”]
interface ArrayConstructor {
new (arrayLength?: number): any[];
…
prototype: Array<any>;
}
declare var Array: ArrayConstructor;
[/sourcecode]と定義されていれば良かったのに。Array
だけではなくて、Object
, Number
, String
等の組み込みオブジェクトも同じ問題を抱えている。
ググってみたらすでに同じ問題で悩んでいる人がいた。
最初のStack Overflowの回答によると、「自前の lib.d.ts
を用意しろ」らしい。つらい。
[2015年1月18日 追記] 以上の問題点はTypeScript 1.4のリリースにより解決しました。詳しくはこちら。