`*.d.ts` ファイルをコミットする前に知ってほしい4つのこと
export type Bookmark = { id: number; url: string; comment: string; }; このファイルには型しか書いてありませんね。ということは、「型定義ファイル」として bookmark.d.ts という名前にするべきでしょうか。実はそうではなく、この場合は bookmark.ts とするべきです。 「型定義ファイル」とは、「どこか別の場所にある実装に型をつけるためのファイル」です。たとえば、以下のファイルは「どこか別の場所にある実装」に型をつけているから、 *.d.ts にするのは自然です。 いっぽう、 type Bookmark は別のどこかにある *.js の型を与えているわけではないので、 *.ts でよいです。 このように本来 *.ts であるべきものを *.d.ts にしてしまうことには問題があります。代表的な問題として型エラ
Rustのopen traitシステム dyno (RFC3192) を読む
dyno (RFC3192) はopen traitのための仕組み (言い換えると、trait downcastingの仕組み) をライブラリレベルで実現する提案です。 できることのイメージ 例として、以下のようなトレイトを考えます。 (std::error::Error を説明のために簡略化したものです) // エラー型はこれを実装する pub trait Error { // エラーの文字列表現を取得する fn to_string(&self) -> String; } これを拡張可能トレイトにするのが本RFCの目的です。 実際の実装はライブラリレベルで行われていますが、わかりやすくするために「拡張構文として書くならこんな感じ」というイメージを先に説明します。 open traitとしての説明 次のように、定義済みのError traitを拡張できる仕組みであると説明できます。 ⚠️こ
事前条件も事後条件もテストも全部 assert!() でいいの？ まあ、いいんじゃないでしょうかという話
事前条件も事後条件もテストも全部 assert!() でいいの？ まあ、いいんじゃないでしょうかという話 Rustでは実行時表明とテスト表明の双方を同じ仕組み (panic機構) を用いて行います。 Rustを書くにあたって、この部分に違和感を覚えた人もいるのではないかと思います (多数派ではないと思いますが)。本稿ではこの違和感について分析し、Rustではそれで問題ないと確認することを目指します。 ※割とフワッとした話に終始します Resultとpanic Rustではエラー処理の方法としてResultとpanicの2種類の方法を提供しています。これは大まかに以下のように使い分けられます。 プログラムが想定しなければいけないエラー (ユーザーが誤った入力を与えた場合や入出力エラーなど) はResultを使う。 プログラムが想定外の状態に陥った場合 (意図しない配列の境界外参照など) はp
JavaScriptのIterator / Generatorの整理
目的と対象読者 IteratorとIterableとGeneratorとGenerator Functionの区別が曖昧な人 (記事前半) Generatorの制御フローを完全理解したい人 (記事後半) の理解を深めるための記事です。 まとめ IteratorとIterableの関係 Iteratorは狭義には呼び出し元の next 呼び出しに応じて要素を出力するインターフェースである。 IterableはIteratorを生成するインターフェースである。 IterableだからといってIteratorとは限らず、IteratorだからといってIterableとは限らない。しかし実際には多くのIteratorはIterableのインターフェースも実装している。 Iterableとコレクションは相互変換可能である。 Iterableは for-of ループで処理できる。 IteratorとG
Cycloneのソースリポジトリを蘇生してみる (前編)
Cycloneとは CycloneはRustのリージョン推論の原型のひとつになった実験的なプログラミング言語です。 現在はメンテナンスされていませんが、歴史的な意義があることからCycloneのビルド環境を整備してみました。 (完結するかは未定) ソースの取得 CycloneのWebサイトは生きているので、ソースはCycloneのDownloadページから取得できます。しかしここに不穏な文言があります。 If you use gcc 4, you must get the latest version of Cyclone from SVN (see below). 最新安定版よりも新しい版があること、またgccのバージョンに依存して壊れることが読み取れます。そしてSubversionと書いてあることから嫌な予感がした人もいると思いますが、このリポジトリは既に動いていません。 というわけで
Temporal Dead Zone と採用されなかった他の候補について
Temporal Dead Zone とは ECMAScript 2015で採用された let/const のスコーピングの仕様をTemporal Dead Zoneと呼びます。 const x = "outer"; { const f = () => x; // console.log(f()); // => Error const x = "inner"; console.log(f()); // => "inner" } 4つの方式 Temporal Dead Zone という名前は、ブロックスコープ変数の挙動を決める際の4つの候補の名前に由来しているようです。 これはECMAScript 4が放棄されて間もない2008年10月のes-discussのログ[1]に言及があります。 A1. Lexical dead zone. References textually prior to
主なNode.js独自API
// CommonJS Modules の場合 const fs = require("fs"); const fs = require("node:fs"); // ES Modules の場合 import fs from "fs"; import fs from "node:fs"; process のように、グローバル変数としても組み込みモジュールとしても提供されているAPIもあります。 global globalThisの別名です。Webブラウザでは window と self がglobalThisの別名として定義されていますが、Node.jsには window や self はなく、かわりに global が定義されています。 Buffer ArrayBuffer, TypedArray (Uint8Arrayなど), DataView はJavaScriptの標準機能です。
Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。本稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり
HTMLパーサーの設計・実装ノート (1) 字句解析
ふと思いつきでHTMLパーサーを書いているので、どのようなことを考えながら実装したかの記録を残します。 (1) 字句解析 (2) 構文解析 おことわり 偏ったこだわりや早すぎる最適化もあるかもしれませんが、あくまで趣味で書いているものなのでご理解ください。そういったもののなかにも、他の人の発想のヒントになるものも含まれると考えています。 途中の試行錯誤のサイクルを省いて結論だけを紹介している箇所もあります。ご了承ください。 ソースコードは https://github.com/qnighy/htstream に上げていますが、現在のところ完成度はそれほど高くありません。ドキュメントもほぼありませんがご了承ください。 HTMLについて HTMLの管轄をめぐっては紆余曲折がありましたが、現在はWebブラウザベンダーを中心とする標準化団体であるWHATWGが制定するHTML StandardがH
TypeScriptのJSDocサポートでできること、できないこと
TypeScriptの主要な入力ファイルは .ts, .tsx, .mts, .cts ですが、JavaScriptファイル (.js, .jsx, .mjs, .cjs) も読み込んで処理することができます。JSDocによる型アノテーションを認識するため、生のJavaScriptでもそれなりに型をつけることができます。 本稿ではタイトル通り、TypeScriptのJSDocサポートでできることとできないこと (.ts でしかできないこと) をまとめます。 おことわり 本記事はTypeScript 4.4時点での実装状況に基づいています。なるべくソースコード中の関係する箇所を参照するようにしたので、今後の変更はご自分で検証してください。 (TypeScript Playgroundで試すだけでも有用です JavaScriptモードで開始できるリンク) JSDocの機能一覧・TypeScri
TypeScriptのdeclareやinterface Windowを勘で書くのをやめる2022
おことわり 個々の関数や変数に正しい型をつける話はしません。TypeScript HandbookのDeclarationの章などを読むことをおすすめします。 かわりに、本稿では関数や変数の型宣言をどこにどう置くべきかの指針を与えます。 モジュールとスクリプト declareを正しく使うにはまずモジュールとスクリプトの区別を理解し、意識することが大切です。 ブラウザやNode.jsは外部からの指定でモジュールとスクリプトを区別しますが、TypeScriptでは原則としてファイルの内容でモジュールとスクリプトを区別します。 import 宣言または export 宣言が1つ以上あればモジュール。 CommonJSモジュールの場合はTypeScript専用構文である import = 宣言、 export = 宣言を使う。 それ以外の場合はスクリプト。 ただし、JavaScriptファイル (
Node.jsのネイティブES Modulesサポートが抱える問題を解決するBabelプラグインを書いた
babel-plugin-node-cjs-interop というパッケージを作ったのでその紹介です。 (GitHub) 何が問題か Node.jsのネイティブES ModulesサポートとBabelやTypeScriptのES Modulesサポートを併用したときに問題が起きます。 ESMとCJS JavaScriptには標準のモジュールシステム (ES Modules, ESM) がありますが、ESMの策定前に先だっていくつかのコミュニティー定義のモジュールシステムが存在していました。そのうちNode.jsを中心として使われていたのがCommonJS Modules (CJS) です。そのNode.js界隈でもESMへの移行が進んでいます。 移行にあたって問題になることのひとつが、ESMとCJSのエクスポートモデルの違いです。 ESMでは、モジュールは0個以上の名前つきエクスポートを定
公式ドキュメントの読み方
「公式ドキュメントを読め」というのが急に話題になっていたので自分なりに整理してみました。 注意: そんなに真面目に推敲していません。フィーリングで書いているので実態に即してない部分もあるかも…… 公式ドキュメントとは何か あなたが使おうとしている道具 (ライブラリ、フレームワーク、プログラミング言語、ミドルウェア、コマンドラインツール、etc.)[1] は必ず誰かによって作られています。ある程度成熟した道具であれば通常、その作った人・組織自身によって公開されているドキュメントがあるはずです。これが公式ドキュメントです。 公式ドキュメントは、OSSにおいてはソースコードと双璧をなす最も信頼できる資料のひとつです。ソースコードが非公開の場合は通常、公式ドキュメントが最も信頼できる資料でしょう。 (以降はOSSを主に想定して説明します) たとえば…… Python のソースコードはGitHub上
ジェネリクス引数の構文的曖昧性まとめ
ジェネリクスを持つ多くの言語では括弧の種類が足りなかったり、既存の文法との互換性を保つために <> をジェネリクス引数に使っている。この文字は比較演算子やシフト演算子にも使われるため、多くの場合は構文的曖昧性の問題がある。 // ジェネリクス引数 (convert<int, string>(number)) // 比較演算子 (score < MAX_SCORE, score > (MIN_SCORE)) 各言語でこの問題をどのように解決しているか調べる。 関連する問題として < > を含むトークン (<<, >> など) をどう分割するかという問題があるが、こちらは本スクラップでは扱わない。
Array.prototype[@@iterator] ←この @@ って何？
MDNにはたまにアットマークを2つ並べた @@ という記法が登場します。 Array.prototype[@@iterator]() The @@iterator method is part of The iterable protocol, that defines how to synchronously iterate over a sequence of values. しかし、この記法をそのままJavaScriptやTypeScriptの処理系に入力しても構文エラーになります。 console.log(Array.prototype[@@iterator]()); // => Uncaught SyntaxError: Invalid or unexpected token ではこの @@ はどこから来て、何を意味する記法なのでしょうか。 結論 これはドキュメント用のwell-
![Array.prototype[@@iterator] ←この @@ って何？](https://cdn-ak-scissors.b.st-hatena.com/image/square/9fd7836534de568251088b204463177b84cac126/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--A7D4VeZL--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3AArray.prototype%25255B%252540%252540iterator%25255D%252520%2525E2%252586%252590%2525E3%252581%252593%2525E3%252581%2525AE%252520%252540%252540%252520%2525E3%252581%2525A3%2525E3%252581%2525A6%2525E4%2525BD%252595%2525EF%2525BC%25259F%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AMasaki%252520Hara%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2l3aEI4dTM5cFZyM09sWVFLcUU5Z1ozV2d3MHlsMS03cUZad0huYWc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
TypeScriptにはanyが4種類、undefinedが3種類、……
このツイートの解説をします。 TypeScriptにはanyは4種類、undefinedは3種類、nullは2種類、trueは2種類、falseは2種類、neverは5種類あるのか。普通に使ってる分にはわからないが…… TypeScriptでは表面上は同じ名前でも内部的に異なる型が割り振られている場合がいくつかあります。そのようなもののうち、プリミティブな型についてまとめました。 対象TypeScriptバージョンは4.1.3です。 2021-01-09 update: 数え方を見直しました。 any が4種類から6種類に増えました。 注意 ここに書かれていることを知らなくても、TypeScriptプログラミングにおいて全く困りません。あくまでコンパイラの機微を楽しむつもりでお読みください。 前提知識 any, undefined, null, true, false, never 型につ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ChromeとSafariのuser agent stylesheet