LuaJIT 3.0 proposed syntax extensions

Status of LuaJIT and relationship to Lua

• Many are surprised/pleased that LuaJIT feature work seems to be resuming after a long maintenance-only phase.
• LuaJIT is reaffirmed as effectively a fork fixed at Lua 5.1, with explicit dislike of later Lua changes.
• Several argue it’s now diverging enough that it’s effectively a new language and might warrant a new name.
• Others counter that 5.1 code will still run, and new features may be opt‑in.

Proposed syntax changes and perceived benefits

• Popular: const keyword, compound assignment (+=, ..=), continue, nil‑coalescing and safe navigation, underscores in numeric literals, string interpolation.
• Supporters say these are mostly “macro‑like” QoL improvements that should be cheap to implement and make Lua more ergonomic and approachable.
• Some draw parallels to Luau (Roblox’s Lua fork) and see alignment as helpful for younger programmers and AI tools.

Ternary operator and if‑expression debate

• Ternary syntax is highly contentious.
• Critics find it redundant, hard to read when nested, and argue Lua already has an idiomatic and/or pattern (with known pitfalls).
• Others prefer making if an expression instead of adding ?:, pointing to Luau‑style if … then … else … expressions.
• A minority likes ternary for concise value selection, especially with immutable variables.

Operators, bitwise syntax, and readability

• Mixed reactions to adding &&, ||, and C‑style bitwise operators.
• Some welcome them for C/JS ergonomics and performance‑oriented interop.
• Others see symbolic operators as unnecessary, visually noisy, and a poor use of rare punctuation, preferring wordy and/or or keyword bitwise ops.

Compatibility, ecosystem, and naming concerns

• Several worry this will fragment Lua further and discourage writing portable scripts, especially given LuaJIT already diverges from PUC Lua.
• Some argue LuaJIT has “stabilized” on 5.1 and that many embedded users prefer that stability.
• Others claim LuaJIT has held back adoption of newer Lua versions and that adding unique syntax deepens the split.

Alternative ideas and projects

• Suggestions include stabilizing LuaJIT bytecode and letting others build alternate syntaxes, or prioritizing compatibility with LuaRocks and PUC Lua over new syntax.
• Mention of alternate VMs and Rust implementations (e.g., supporting multiple Lua versions) as different approaches to the version‑split problem.