LuaJIT 3.0 提议的语法扩展
LuaJIT 3.0 proposed syntax extensions

原始链接: https://github.com/LuaJIT/LuaJIT/issues/1475

此总议题作为讨论与追踪 LuaJIT 3.0 语法扩展的核心中心。该项目的目标是在保持与现有 Lua 标准严格兼容的同时,引入能够提升开发者体验的功能。 为确保进展高效,所有提案必须满足特定准则:必须在其他语言中已得到验证,避免语法歧义,保持向后兼容性,并支持工具开发者(如 LSP 和格式化工具)。该项目秉持简洁的理念,明确拒绝 C++ 或 Perl 等语言中存在的复杂性。 鼓励参与者提供侧重于功能性的建设性反馈,而非主观的审美偏好或对微小符号的“琐碎争论”(bike-shedding)。作者强调,虽然重视与既有语言的一致性,但首要目标是实现一种简洁、实用的语言演进。议题 #63 和 #1379 已合并至此处,以简化讨论流程。

抱歉。
相关文章

原文

This is an umbrella issue for the LuaJIT 3.0 syntax extensions.

The documentation will be evolved and updated in the first comment below. 1

Please feel free to discuss the choice, design and semantics of syntax extensions in this issue. Improvements and clarification requests for the documentation are welcome, too.

As syntax preferences are largely subjective, please ensure feedback remains constructive. If a specific proposal is declined, please respect the decision and move on. In general, I hope we can keep the discussion focused on functionality and avoid prolonged discussions about cosmetic symbol choices for edge-case operators (aka bike-shedding).

Some of the syntactic choices have already been made by others (C, Lua, JavaScript, …) — and I'm definitely not happy with all of them. But there's value in conformity and compatibility.

The goal is to only add syntax extensions that:

  1. Improve developer quality-of-life.
  2. Are proven. In other languages or Lua dialects.
  3. Do not create syntactic ambiguities.
  4. Do not break backwards compatibility.
  5. Do not make life difficult for tool developers (syntax formatters, LSPs).

Just to make this clear: I have no intention to copy the syntactic complexity of Perl, Ruby, C++ or Rust.

The related issues #63 and #1379 have been closed in favor of this issue.

联系我们 contact @ memedata.com