功能提案

wiki

核心

• Lua 函数调用可能会无限期阻塞。带有 yield 的调试钩子只能部分解决这个问题。参见 非阻塞 Lua 执行。
• 支持 64 位整数作为 Lua 的原生类型。当前的 'number' 类型使用双精度浮点数，无法提供 64 位精度，但许多嵌入 Lua 的应用程序需要 64 位整数，迫使它们使用用户数据来处理 - 但这对于标准库函数（如 math 和 tonumber() 的强制转换）来说并不适用。考虑到大多数计算机现在都是 64 位 CPU，并且在下一个主要 Lua 版本流行之前，更多计算机将成为 64 位 CPU，使用 64 位整数的能力将变得越来越重要。

库和功能

• 缺乏对常用非 ANSI C 功能的标准化（例如 chdir/list-dir、sleep 等）。参见 标准库/扩展提案。一个建议是 Lua 至少定义这些函数的接口，即使它不包含实现（出于 ANSI C 的原因）。
• 允许 table.sort() 的链式调用。使 table.sort(t, comp) 返回 t，就像 setmetatable() 一样。这似乎只是在 ltablib.c 的 sort() 函数中添加一个 lua_settop(L, 1); 并将返回值从 0 更改为 1 的问题。
• 运行时序列化。 Engram 提案 利用 dump 格式进行消息传递和持久化序列化。

语法

• 宏/语法扩展功能是普遍需要的。有各种实现：Metalua[1]、luaSub[2]、LuaFish、LuaMacro 和 token 过滤器。
• 简短匿名函数 很冗长，例如 |x| x*x 而不是 function(x) return x*x end。这经常被注意到。
• 表达式中的语句 不受支持（除非使用匿名闭包），这限制了表达能力和一些宏的应用。
• 自定义运算符 目前不受直接支持。
• 连接运算符 .. 的结合性为右结合，并且限制为大约 200 次连接（^ 也是如此），这可能是一个限制。
• 三元运算符（条件表达式，如 C 中的 a ? b : c）只能通过 x and y or b 部分近似。
• ":" 和 "." 有时会混淆 - 参见 冒号用于方法调用。
• 表达式作为语句 将缩短一些代码。
• 八进制和二进制表示的常量，例如 0d81 0o722 0b0101011101011101111，不受直接支持。
• MakeSuperfluousTokensOptional（例如“then”和“do”）。其他人对此强烈反对。这似乎不太可能，除非例如通过令牌过滤。
• 一些 Lua 的语法（例如 ~ =）对于来自 C 语言背景的人来说并不熟悉（！=）。参见 SyntaxAddition。
• MethodCurry - 使方法调用（foo:bar()）在没有调用部分（foo:bar）的情况下评估为柯里化闭包

语义

• CountingFromOne 困扰着一些人。
• dofile 不会在调用者环境中执行，而是在全局环境中执行：DofileNamespaceProposal。
• 在运行时获取 Lua 函数的源代码：DumpingFunctionsSourcecode
• InfAndNanComparisons 可能会被引入（就像 C 中现有的那些）。

表达能力

• nil 和 NaN 不能存储在表中 - 参见 StoringNilsInTables
• 并非所有对象都完全可虚拟化。具有元表的对象目前不能像其他类型的值一样工作，包括内置类型。 LuaVirtualization / GeneralizedPairsAndIpairs
• I/O 库抽象。I/O 库假定使用标准文件句柄（stdout/stderr/stdin）。对于嵌入式系统、游戏机和 GUI 应用程序，情况并非总是如此。需要修补 liolib.lua。参见 LuaList:2008-07/msg00345.html 。
• 可变参数和元组。参见 VarargTheSecondClassCitizen 。这可能允许更轻松、更高效地存储和操作可变参数（...）。此外，Rici 的不可变元组类型提案，带有后缀解包运算符 ...，例如 e = <4,5>; assert(e[2] == 5); assert(#e == 2); a,b,c... = d,e...; assert(c == <5>); assert(<2,3> .. <4> == <2,3,4>); t[<2,3>] = <3,4>; function f(a...) return function(b...) return a,b end end; assert(<f<1,2><3,4>> == <<1,2>,<3,4>>)
• TableScopeBlocks - 支持新的“using..in..end”块，将全局作用域更改为表作用域

代码质量/正确性/错误处理

• module 函数在模块定义中暴露了许多缺陷：LuaModuleFunctionCritiqued。可能消除或修改此函数。
• 异常处理限制。作用域退出时的资源清理将避免以笨拙的方式编写某些程序以确保正确性（例如，在异常时关闭文件句柄）。参见 ResourceAcquisitionIsInitialization。建议使用 try/finally、RAII 和作用域退出块。参见 Lua 编程宝石第 13 章，了解这些限制。
• error(message,level) 中的 level 难以管理。它甚至没有在 assert 中设置 - 参见 LuaCarp。
• DetectingUndefinedVariables 对于许多用户来说还不够。建议将 checkglobals 函数包含在内（除了现有的 etc/strict.lua 和 test/globals.lua 解决方案）。
  • 子问题：向调试库添加功能，以列出另一个函数访问的全局变量，可能类似于 lhf 的 lbci[3]。参见 DetectingUndefinedVariables 中的“checkglobals”，了解用例。
• 回顾 Lua 范围 (LocalByDefault)。 一些人建议“默认无” (既不是“默认局部”也不是“默认全局”)。 另请参阅与 DetectingUndefinedVariables 相关的部分。

打包

• 类似于 Perl CPAN 的 Lua 包管理器 是许多用户推荐的。 LuaRocks 正在朝着这个方向发展。

编码风格

• Lua 源代码中需要更多注释。 这些注释可以是内部的，也可以是外部的 (例如，解释源代码的书籍)。 请参阅 LuaSource。

未分类

• TrailingNilParameters - C 和 Lua 在处理额外 (或缺失) 参数方面的差异有时会令人困惑...
• TableConstructors - 更好的表格构造器语法提案
• PackagingLuaLibraries - 关于打包标准化的评论
• type() 函数对于找出内置 Lua 类型很有用，但对于面向对象的表格/用户数据则无用。 能够有一个新的 typeof() 函数来检查其参数是否存在新的元方法 '__typeof' 将很不错。 例如，嵌入式应用程序可以为其推送的每个用户数据类/对象提供一个 metatable '__typeof' 字符串作为其类型，而提供基于表格的对象的 Lua 模块也可以这样做。

用户维护的列表

这些用户页面维护着功能提案列表

• JohnBelmonte
• RiciLake
• DavidManura

Lua 5.2

• 协程让步 不支持所有用例。 请参阅跨越 pcall 的 yield [4]、YieldableForLoops、ResumableVmPatch、[coxpcall]。 在 5.2 中大部分已解决。
• 弱表格 在键和值之间建立了一种偶然关系，这种关系是垃圾回收算法不知道的。 请参阅 GarbageCollectingWeakTables。
• 位运算符 经常需要，但在 5.2 之前，标准 Lua 发行版中没有。 它们经常被请求，并且有许多竞争实现。
• 循环中的continue语句不可用。很多人要求过这个功能。参见ContinueProposal。（在 5.2 中通过 goto 语句解决。）
• FrontierPattern %f 模式表达式在 5.2 之前没有文档记录。
• 允许 Lua 解释器从模块搜索路径中定位脚本。参见ModuleExecutionProposal。在 Lua 5.2 中以 package.searchpath 的形式公开。

另请参见LuaFiveTwo。

已解决的问题

这些问题已关闭、撤回或已实施。

• BooleanTypeProposal - 区分nil和false
• LuaTableSize - 关于 Lua 臭名昭著的“n”字段的讨论（尽管在StoringNilsInTables中仍然有一些问题）
• HereDoc - heredoc 支持 - 撤回的提案

Lua 补丁

一些功能已作为非标准补丁实现：LuaPowerPatches。其他想法在MetaLuaRecipes中实现。

其他示例

这将打印“1”。可能最好要求“--[[”注释以“--]]”而不是“]]”结束。

--[[
  g = f[x[y]]
  print(1)
--]]

个人评论

我们可以从本页中删除不是实际功能提案的项目（例如StoringNilsInTables）吗？也许可以开始 LuaWarts?

我已经开始根据各种问题类别来重构此页面，每个类别包含一些已识别的问题，每个问题都有零个或多个提出的解决方案。我认为，在决定语言如何演变时，问题本身比任何一个提出的解决方案都更重要和有趣。此外，ResourceAcquisitionIsInitialization 和 DetectingUndefinedVariables 页面的结构值得注意：它们同样描述了一个问题，并随后列出了各种解决方案（包括设计模式、补丁、元编程/源代码过滤解决方案、提出的语言更改等），因此非常适合这种结构。不过，也许这一切都应该放在另一个页面上。并非所有这些问题都一定可以通过语言更改来解决，但它们的存在可能是至少考虑语言更改的一个理由。--DavidManura