功能提案

wiki

核心

• Lua Function 呼叫可能無限期地封鎖。具備讓步的 debug hooks 僅提供此問題的部分解決方式。請參閱 NonBlockingLuaExecution。
• 將 64 位元整數作為原生 Lua 型別提供支援。目前標示為 double 型別的「數字」型別不會提供 64 位元的精確度，但許多嵌入 Lua 的應用程式需要 64 位元整數，這會強制它們使用使用者資料來處理。然而，這對於 math 和 tonumber() 強制轉換等標準函式庫功能沒有用。考量大多數電腦目前都是 64 位元 CPU，而且在下一個主要的 Lua 版本開始普及時，會有更多電腦使用，因此使用 64 位元整數的功能將會越來越重要。

函式庫和功能

• 針對一般需要的非 ANSI C 功能，缺少標準化。（例如 chdir/目錄清單、睡眠...）。請參閱 StandardLibraries/ExtensionProposal。一個建議是讓 Lua 至少為這些功能定義介面，即使它未包含實作（考量到 ANSI C 的緣故）。
• 允許連鎖 table.sort()。讓 table.sort(t, comp) 傳回 t，就像 setmetatable() 所做的一樣。這似乎只需在 ltablib.c 的 sort() 功能中新增 lua_settop(L, 1);，並將傳回值從 0 變更為 1 即可達成。
• 執行階段串列化。EngramProposal 利用傾印格式來進行傳訊和持久性串列化。

語法

• 常會需要巨集/語法擴充功能。有許多種實作方式：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 部分近似達成。
• ：「」和「。」有時會造成混淆，請參閱 ColonForMethodCall。
• 表達式當作陳述式可以縮短一些程式碼。
• 八進位和二進位表示法的常數，例如 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
• 輸入/輸出函式庫抽象。輸入/輸出函式庫假設使用標準檔案處理（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 - 支援新的「用...在...中...結束」區塊，將全域範圍變更為表格範圍

程式品質/正確性/錯誤處理

• module 函式在模組定義中暴露許多缺陷：LuaModuleFunctionCritiqued。可能消除或修改此函式。
• 例外處理限制。範圍結束時的資源清除會避免必須以笨拙的方式撰寫程式來確保正確性（例如在發生例外情況時檔案處理器會關閉）。請參閱 ResourceAcquisitionIsInitialization。建議使用 try/finally、RAII 和範疇退出區塊。請參閱 Lua 程式設計精華的第 13 章，了解這些限制。
• error(message,level) 中的 level 管理起來很麻煩。它甚至未設定在 assert 中—請參閱 LuaCarp。
• DetectingUndefinedVariables對許多使用者來說並不夠用。建议加入checkglobals函数（除了現有的 etc/strict.lua 和 test/globals.lua 解决方案之外）。
  • 子议题：在 debug 库中加入列出另一个函数所存取的全局变量的功能，可能类似于 lhf 的 lbci[3]。请参阅DetectingUndefinedVariables中的“checkglobals”以了解使用案例。
• 检阅 Lua 范围规则（LocalByDefault）。有些人建议“无预设”（既不是“预设为 local”也不是“预设为 global”）。请也参考DetectingUndefinedVariables。

封装

• 许多使用者建议为 Lua 建立类似 Perl CPAN 的机制。 LuaRocks 正朝此方向发展。

编码风格

• 许多人要求在 Lua 原始碼中加入更多注解。这些注解可以是原始碼内部的，也可以是外部的（例如一本解释原始碼的书籍）。请参阅LuaSource。

未分类

• TrailingNilParameters - C 和 Lua 在处理多余（或缺少）参数时，有时会出现令人困惑的差异...
• TableConstructors - 建议使用更好的表格建构语法
• PackagingLuaLibraries - 有关封装标准化的注解
• type() 函数可用于找出内建的 Lua 类型，但无法用于面向对象的表格/userdata。很希望有一个新的 typeof() 函数，可针对其 arg 检查新的元方法“__typeof”。例如，嵌入式应用可以替它推送的每个 userdata 类别/对象提供一个元表来 __typeof 字符串作为其类型，而提供表式对象的 Lua 模块也可以这么做。

使用者维护清单

这些使用者页面维护了功能建议清单

• JohnBelmonte
• RiciLake
• DavidManura

Lua 5.2

• 协程 yielding 并不支持所有使用案例。请参阅 pcall[4]、YieldableForLoops、ResumableVmPatch、[coxpcall]中的yield。已在 5.2 中大多解决了。
• 弱表建立了键和值之间的应急关系，但垃圾回收算法并不了解这项关系。请参阅GarbageCollectingWeakTables。
• BitwiseOperators 很常需要，但在 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 Patch

某些功能早已非標準 patch 形式執行：LuaPowerPatches。而其他構想則在 MetaLuaRecipes 中執行。

其他範例

這會印出「1」。或許會更好，需要「--[[」註解以「--]]」終止，而不是僅有「]]」

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

個人意見

我們可以從此頁面中移除未實際提出功能建議的項目嗎（例如 StoringNilsInTables）？或許可以先建立 LuaWarts？

我已開始重新整理此頁面，採用各種類別的問題，每種類別都包含已識別的若干個問題，而每個問題則有零個或多個建議的解決方案。在決定程式語言應如何演進時，我想這些問題本身比任何一個建議的解決方案都比較重要且有趣。而且，ResourceAcquisitionIsInitialization 和 DetectingUndefinedVariables 頁面的架構也值得注意：它們同樣描述一個問題，然後提出各種解決方案（包括設計模式、patch、元程式設計/原始程式過濾解決方案、提議的語言變更等），因此很適合這個架構。也許所有這些都應該屬於不同的頁面。並不是所有這些問題都一定由語言變更解決，儘管這些問題的存在至少可能會是一個考慮要進行語言變更的原因。--DavidManura