Programming Viewing with Reserved Keywords

Transcript

1. 予約語で見る プログラミング言語 Matsuriba Max 2026 ライガー 1 / 25
2. Q. 予約語って？ 2 / 25
3. 予約語って？ • ユーザーが再定義できない文字列 （記号を除く） • ＝識別子（変数名・関数名）として使えない • 例：Python の for if while など • 言語の「制御構造」 「型」 「宣言」 「実行制約」など 3 / 25
4. 予約語って？ • なぜその文字列を予約語にするのか • → 組み込み関数でも良くない？ • 予約語＝プログラマに意味を上書きされたくない • 単純な関数の場合（言語によるが）オーバーライドされる • if-else は分岐処理しか許さない • while はループ処理しか許さない • 言語の設計思想が出やすい要素の一つ 予約語をテーマに言語の世界を見てみよう 4 / 25
5. おしながき • 言語の設計思想に触れることができる • 業界トレンドと予約語の変更 • 予約語戦略から見るソフトウェア設計 5 / 25
6. 言語の設計思想に触れることができる 6 / 25
7. 言語の設計思想に触れることができる • プログラミングは計算モデルを実行命令に変換する •「計算モデル」ー「実行命令」のギャップを埋める • 予約語は言語がやりたいことを端的に表す要素 • その言語が何を大事にしているか、予約語にも表れる 予約語に設計思想が顕れる 7 / 25
8. 予約語と設計思想 defer と mut Go: `defer` defer_go.go func process() error { f, err := os.Open("data.txt") if err != nil { return err } defer f.Close() // 関数終了時に必ず実行 data, _ := io.ReadAll(f) fmt.Println(string(data)) return nil } Rust: `mut` mut_rs.rs fn main() { let x = 5; // デフォルトは不変 // x = 6; // コンパイルエラー let mut y = 5; // mut で可変性を明示 y = 6; // OK: 変更を意図的に 宣言している } 8 / 25
9. おしながき • 言語の設計思想に触れることができる • 業界トレンドと予約語の変更 • 予約語戦略から見るソフトウェア設計 9 / 25
10. 業界トレンドと予約語の変更 10 / 25
11. コールバック地獄と非同期構文の需要 • 2010 年代〜: Web API・DB・ファイル I/O など「待ち」が当たり前に •「C10K 問題」の解決策として非同期処理が注目される • 従来のコールバック方式では可読性が急激に低下 callback_hell.js // コールバック地獄（Promise 普及以前の JavaScript） fetch('/api/user', function(data) { parse('/api/order', data, function(order) { calc('/api/item', order, function(item) { // ネストが深くなる一方... }); }); }); より直感的な非同期構文「async/await」を使いたい！ 11 / 25
12. async/await が予約語になるまで F# 2007 C# 5.0 2012 Python 3.5 2015 JavaScript 2017 Python 3.7 2018 Rust 2019 C++20 2020 Swift 5.5 2021 C# 5.0（2012）を皮切りに主要言語へ次々と伝播 12 / 25
13. 予約語への昇格が引き起こしたこと Before: Python 3.7 未満 celery_old.py # Kombu / Celery の典型的な書き方（Python 3.7 以前） result = group(tasks).apply_async(async=True) task.apply(async=False, countdown=10) # async=True でバックグラウンド実行するかど うかを制御 After: Python 3.7 以降 celery_new.py # Python 3.7 以降の修正版 result = group(tasks).apply_async(is_async=True) task.apply(is_async=False, countdown=10) # async が予約語になったため引数名をリネー ム 引数名 1 語の変更でエコシステム全体が揺れた 13 / 25
14. Python の対応：予約語の段階的昇格 Python 3.5（2015）ソフトキー ワード • 変数名・引数名としても使用可能 • async def 構文が使えるようになる • 既存コードへの影響なし • ライブラリが対応期間を確保 Python 3.7（2018）厳格な予約語 • 変数名・引数名として使用不可 • async=True のようなコードが構文エ ラー • Celery・Kombu などが対応を余儀 なくされる • is_async=True などへのリネームが 必要 14 / 25
15. async/await の予約語対応から見えること • 業界トレンドの変化は言語を変える圧力になる • 予約語 1 語の変更 = 既存コード全体への影響 • 各言語はそれぞれの戦略でこれに対処した 言語 戦略 破壊的変更 Python ソフト KW → ハード KW の段階移行 あり（3.7） JavaScript strict mode（オプトイン） 最小限 Rust エディション制（プロジェクト単位） エディション内のみ C# コンテキストキーワードとして追加 なし 「いつ・どう変えるか」が言語設計の本質的な問い 15 / 25
16. おしながき • 言語の設計思想に触れることができる • 業界トレンドと予約語の変更 • 予約語戦略から見るソフトウェア設計 16 / 25
17. 予約語戦略から見るソフトウェア設計 17 / 25
18. 「使われていない」予約語 • 将来使うかもしれない語を初期段階で先行確保する戦略 • 後から追加するほど既存コードへの影響が大きくなるため • このような予約語を Future Reserved Words と呼ぶ • Java の const / goto：Java 25 現在も機能しないまま残り続けている • JavaScript ES5 は逆に、予測外れの FRW を大量に削除する決断 「負債として受容」するか「破壊的変更を行う」か 18 / 25
19. 予約語は先行確保？ 必要な時に追加？ 先行確保（Java スタイル） • 将来の需要に備えて早めに確保 • 予測が当たれば後の破壊的変更を 回避 • 予測が外れると • → 未使用の負債に 必要になったら追加 • 今必要なものだけ実装する • 後から追加するほど • → 既存コードへの影響大 19 / 25
20. Rust エディション制：第三の道 • プロジェクト単位で言語仕様のバージョンを選択できる • エディション内は互換性を保つ方針 rust_edition.toml [package] name = "my-app" version = "1.0.0" edition = "2021" # ← ここで予約語セットのバージョンを指定 # edition = "2015" # gen は識別子として使える # edition = "2024" # gen が予約語になる 「プロジェクトごとにルールを選ぶ」柔軟な戦略 20 / 25
21. 予約語戦略から得られる教訓 • 拡張性のための先行設計か、YAGNI か • → 予測精度 × 変更コストで判断が変わる • 互換性維持のコストを誰が払うか • Java: 言語が払う（負債として保持） • JavaScript: 生態系が払う（大量の修正） • Rust: 開発者が選ぶ（エディション移行） • 変更の影響範囲を仕組みで制御する 「変更とどう向き合うか」は言語設計もプロダクト開発も同じ問い 21 / 25
22. 今日から試せること • Python なら import keyword; print(keyword.kwlist) を叩いてみる • 手元で予約語一覧がすぐ確認できる • 新しい言語を学ぶとき「何が予約語か」から入ってみる • 設計思想の輪郭がつかめる • 自分のコードでも「この名前を上書きされたくない」か考える 予約語は言語設計者のメッセージ……かもしれない 22 / 25
23. 記事も公開しています Zenn にて公開中です！ぜひ読んでみてください 23 / 25
24. ご清聴ありがとうございました 24 / 25
25. 25 / 25