ハクソク

世界を動かす技術を、日本語で。

LuaJIT 3.0 提案された構文拡張

2026年6月25日原文(github.com)

概要

  • LuaJIT 3.0 の構文拡張に関する 総合的な議論 の場
  • ドキュメント は随時 更新予定、最初のコメントで管理
  • 建設的な議論 と 機能性重視 のフィードバック推奨
  • 後方互換性 や ツール開発者への配慮 を重視
  • PerlやRustのような 複雑な構文 は導入しない方針

LuaJIT 3.0 構文拡張 総合イシュー

  • LuaJIT 3.0 における 構文拡張 の議論用イシュー
  • 構文拡張の選定・設計・意味論 について自由に議論可能
  • ドキュメントの改善や明確化 の要望も歓迎
  • 構文の好み は主観的なため、 建設的な意見交換 を希望
    • 却下された提案 には固執せず、次の議題へ移行
  • 議論の焦点 は 機能性 に置き、 記号や細部の議論 （いわゆるバイクシェディング）は最小限に
  • C, Lua, JavaScript など、既存言語の構文選択に合わせる方針
    • 互換性や慣習 の価値を重視
  • 追加する構文拡張の条件
    • 開発者の利便性向上
    • 他言語やLua方言での実績
    • 構文的な曖昧さの回避
    • 後方互換性の維持
    • ツール開発者への配慮 （フォーマッタやLSPなど）
  • Perl、Ruby、C++、Rust のような 複雑な構文 の導入は行わない方針

関連イシューとドキュメント方針

  • #63 および #1379 は本イシューに統合し クローズ済み
  • LuaJIT は過去に多くの 拡張 を蓄積
    • ドキュメント が分散していたため、 統合的な新ドキュメント を作成予定
    • 各拡張 には 登場バージョン を明記
    • 本イシューのコメント で随時 ドキュメント追加・更新 予定

議論・フィードバックのガイドライン

  • 構文拡張の選択や設計 に関する 意見交換 の場
  • 明確化・改善要望 も 歓迎
  • 却下された提案 については 決定を尊重
  • 機能性重視 の議論を推奨
  • 記号や細かい構文選択の長期議論 は 避ける方針

今後のドキュメント計画

  • LuaJIT全体の統合ドキュメント 作成
    • 拡張ごとに登場バージョンを明記
    • 本イシューのコメント欄 で 随時更新
  • 開発者・ツール製作者 の 利便性向上 を目指す

Hackerたちの意見

じゃあ、LuaJITは約10年のメンテナンス期間を経て、アクティブな開発を再開するの？それは素晴らしい！これらの変更の多くは納得できるけど（ただ、いくつかはちょっとTIMTOWTDIすぎるかな）、LuaJIT 3は名前を変えた方がいいかもね。確かに、これだけの変更があれば、単なるLuaのJITコンパイル版というより、別の言語に近い感じになるよね。

└

TIMTOWTDI これって一体何を意味してるの？

└

その中のいくつかはLuauから来てるんだ。RobloxのLuaフォークで、若いプログラマーたちが一番知ってる方言だね。LuaJITにそれを追加すれば、ZoomerやAIエージェントがLuauコードに触れてるから、書きやすくなるよ。

JavaScriptっぽいね。これらの変更は本当にQoL向上に見える。特に三項演算子が使いやすくなるとは思えないな。示された例もあまり説得力がないし、「見た目が整ってる」ってのは読みやすいとは違うからね。

└

さらに悪いことに、C（!や&&みたいな）やPerl（明らかにいろんなやり方がある）を見てると、ほんとに改善点があるんだよね。例えば、デフォルトでnullを許容するための?.や??=みたいなやつ。三項演算子はすごく便利だけど、もっと慣用的に実装されるのがいいな。pos += (if forward then +1 else -1)みたいな感じで。構造的パターンマッチングは素晴らしいかもしれないけど、提案されてる構文はないね。

└

Luaは、いつもJavaScriptっぽいなって感じてた。文法が違うだけで。

└

どこかのインターネットで、LuaとJS（正確にはECMAScript）の言語設計が何か関係あるって見たことがあるんだけど、具体的な参照が見つからないんだよね…それを読んだのはずいぶん前だから。

三項演算子は絶対に理解できないわ。導入した途端に、どこでも使いたがる奴が出てくるし、ネストされた三項演算子が許されるとさらに厄介。コードゴルフには便利かもしれないけど、結局は冗長な構文にしか見えないし、せいぜい数文字の節約になるだけだよね。

└

Luaは基本的に「and」と「or」がショートサーキットするから、三項演算子みたいなもんだよね。だから、わざわざ新しい構文を追加する必要はないと思う。local x = condition ? value_a : value_b じゃなくて、local x = condition and value_a or value_b で十分だよ。

└

JSの場合は、ファイルサイズを小さくするために数文字削るのが意味あるかもしれないけど、一般的にはコードの明瞭さと「自己説明性」を重視してるかな。

└

だから「if」はただの式にすべきだよね。

└

変わらない変数がある言語では、単純な条件から値を得るときに可変変数や余分な関数を避けるために、三項演算子が一番役立つと思うよ。

Hacker Newsで議論の続きを見る