Feature Proposals

wiki

Core

• Lua function calls can block indefinitely. Debug hooks with a yield provide only a partial way around this. See NonBlockingLuaExecution.
• Support 64-bit integers as a native Lua type. The current 'number' type as a double doesn't give 64-bit precision, but many apps which embed Lua need 64-bit integers, forcing them to handle it with a userdata - but that doesn't work for standard-library functions like math and tonumber() coercions. Considering most computers are now 64-bit CPUs and more will be by the time the next major Lua version becomes popular, the ability to use 64-bit integers will become more important.

Libraries and Functionality

• Standardization for commonly needed non-ANSI C functionality is lacking (e.g. chdir/list-dir, sleep, ...). See StandardLibraries/ExtensionProposal. One suggestion is for Lua to at least define the interface for these function even if it does not include an implementation (for ANSI C reasons).
• Allow chaining of table.sort(). Make table.sort(t, comp) return t just like setmetatable() does. This seems to be just a matter of adding a lua_settop(L, 1); and changing the return value from 0 to 1 in the sort() function of ltablib.c.
• Runtime Serialisation. The EngramProposal to leverage the dump format for messaging and persistence serialisation.

Syntax

• A macro/syntax-extension facility is commonly wanted. There are various implementations: Metalua[1], luaSub[2], LuaFish, LuaMacro, and token filters.
• ShortAnonymousFunctions are verbose, e.g. |x| x*x rather than function(x) return x*x end. This is fairly frequently noted.
• StatementsInExpressions are not supported (without resorting to anonymous closures), which limits expressibility and some macro applications.
• CustomOperators are currently not directly supported.
• AssociativityOfConcatenation .. is right associative and limited to about 200 concatentations (same for ^), which may be a limitation.
• TernaryOperator (conditional expressions as in C's a ? b : c) are only partly approximated by x and y or b.
• ":" and "." can sometimes be confused -- see ColonForMethodCall.
• ExpressionsAsStatements would shorten some code.
• Constants in octal and binary notation, e.g. 0d81 0o722 0b0101011101011101111, are not directly supported.
• MakeSuperfluousTokensOptional (e.g. 'then' and 'do'). Others strongly objection to this. This seems unlikely except e.g. via token filtering.
• Some Lua's syntax (e.g. ~=) is unfamiliar to those coming from a C language background (!=). See SyntaxAddition.
• MethodCurry - have method calls (foo:bar()) without the call part (foo:bar) evaluate to curried closures

Semantics

• CountingFromOne bothers some people.
• dofile doesn't execute in the caller environment but rather in the global one: DofileNamespaceProposal.
• Obtaining the source of a Lua function at run-time: DumpingFunctionsSourcecode
• InfAndNanComparisons might be introduced (like the existent ones in C).

Expressibility

• nil and NaN cannot be stored in tables -- see StoringNilsInTables
• Not all objects are fully virtualizable. An object with a metatable currently cannot act as if it were a value of any other type, including the built-in types. LuaVirtualization / GeneralizedPairsAndIpairs
• I/O library abstraction. The I/O library assumes standard file handles are used (stdout/stderr/stdin). This is frequently not the case for embedded systems, game consoles, and GUI applications. Patching liolib.lua becomes necessary. See LuaList:2008-07/msg00345.html .
• Varargs and tuples . See VarargTheSecondClassCitizen . This might allow varargs (...) to be stored and manipulated more easily and efficiently. Also, Rici's immutable tuple type proposal with postfix unpack operator ..., e.g. 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 - support new "using..in..end" block to change global scope to table scope

Code Quality/Correctness/Error Handling

• The module function exposes many warts in module definition: LuaModuleFunctionCritiqued. Possibly eliminate or modify this function.
• Exception handling limitations. Resource clean-up on scope exit would avoid needing to write some programs in an awkward way to ensure correctness (e.g. file handle close upon an exception). See ResourceAcquisitionIsInitialization. try/finally, RAII, and scope exit blocks are proposed. See Chapter 13 of Lua Programming Gems concerning these limitations.
• level in error(message,level) is cumbersome to manage. It's not even set in assert -- see LuaCarp.
• DetectingUndefinedVariables is not sufficient for a number of users. The checkglobals function was recommended for inclusion (in addition to the existing etc/strict.lua and test/globals.lua solutions).
  • Sub-issue: Add to the debug library the capability to list the global variables accessed by another function, possibly along the lines of lhf's lbci[3]. See "checkglobals" in DetectingUndefinedVariables for use case.
• Review Lua scoping (LocalByDefault). Some have recommended that "nothing-by-default" (neither "local-by-default" not "global-by-default). See also in relation to DetectingUndefinedVariables.

Packaging

• Something like Perl CPAN for Lua is recommended by a number of users. LuaRocks is moving in this direction.

Coding Style

• More comments in the Lua source have been required by a number of people. This may be internal to the source or external (e.g. a book explaining the source code). See LuaSource.

Uncategorized

• TrailingNilParameters - differences in the handling of extra (or missing) parameters in C and Lua can sometimes be confusing...
• TableConstructors - better table constructor syntax proposal
• PackagingLuaLibraries - comments on packaging standardization
• The type() function is useful for figuring out built-in Lua types, but not for object-oriented tables/userdata. It would be nice to have a new typeof() function which checks its arg for a new metamethod '__typeof'. For example, an embedding app could give each userdata class/object it pushes a metatable __typeof string for its type, and a Lua module providing table-based objects can do likewise.

User Maintained Lists

These user pages maintain lists of feature proposals:

• JohnBelmonte
• RiciLake
• DavidManura

Lua 5.2

• Coroutine yielding didn't support all use cases. See yield across a pcall[4], YieldableForLoops, ResumableVmPatch, [coxpcall]. Mostly resolved in 5.2.
• Weak tables establish a contingency relationship between key and value which is not known to the garbage collection algorithm. See GarbageCollectingWeakTables.
• BitwiseOperators are frequently needed but were not in the standard Lua distribution until 5.2. They were frequently requested and there are many competing implementations.
• continue statements in loops are not available. This has been asked for by quite a few people. See ContinueProposal. (Resolved with goto statements in 5.2.)
• The FrontierPattern %f pattern expression was undocumented until 5.2.
• Allow the Lua interpreter to locate a script from the module search path. See ModuleExecutionProposal. Exposed in Lua 5.2 as package.searchpath.

See also LuaFiveTwo.

Past Resolved Issues

These issues were closed, retracted, or since implemented.

• BooleanTypeProposal - making a distinction between nil and false
• LuaTableSize - discussion about Lua's infamous "n" field (though there are still some issues noted in StoringNilsInTables above)
• HereDoc - heredoc support - retracted proposal

Lua Patches

Some features have been implemented as a non-standard patch: LuaPowerPatches. Other ideas are implemented in MetaLuaRecipes.

Miscellaneous Examples

This prints "1". Possibly would be better to require that "--[[" comments terminate with "--]]" rather than just "]]".

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

Personal Comments

Can we remove items that are not actually feature proposals from this page (e.g. StoringNilsInTables)? Perhaps start LuaWarts?.

I've started restructuring this page in terms of various classes of problems each containing some number of identified problems each having zero or more proposed solutions. I think the problems themselves are more important and interesting than any one proposed solution when deciding how the language should evolve. Also, the structure of the ResourceAcquisitionIsInitialization and DetectingUndefinedVariables pages is noteworthy: they similarly describe a problem and follow it by various solutions (including design patterns, patches, metaprogramming/source-filtering solutions, proposed language changes, etc.) and therefore fit this structure well. Still maybe this all belongs on a different page. Not all these problems are necessarily solved by language changes, though the existence of them could be a reason to at least consider language changes.--DavidManura