This month Luau team has worked to bring you a new language feature together with more type checking improvements and bug fixes!
Generalized iteration
We have extended the semantics of standard Lua syntax for iterating through containers, for vars in values with support for generalized iteration.
In Lua, to iterate over a table you need to use an iterator like next or a function that returns one like pairs or ipairs. In Luau, you can now simply iterate over a table:
for k, v in {1, 4, 9} do
assert(k * k == v)
end
This works for tables but can also be customized for tables or userdata by implementing __iter metamethod. It is called before the iteration begins, and should return an iterator function like next (or a custom one):
local obj = { items = {1, 4, 9} }
setmetatable(obj, { __iter = function(o) return next, o.items end })
for k, v in obj do
assert(k * k == v)
end
The default iteration order for tables is specified to be consecutive for elements 1..#t and unordered after that, visiting every element.
Similar to iteration using pairs , modifying the table entries for keys other than the current one results in unspecified behavior.
Typechecking improvements
We have added a missing check to compare implicit table keys against the key type of the table indexer:
-- error is correctly reported, implicit keys (1,2,3) are not compatible with [string]
local t: { [string]: boolean } = { true, true, false }
Rules for == and ~= have been relaxed for union types, if any of the union parts can be compared, operation succeeds:
--!strict
local function compare(v1: Vector3, v2: Vector3?)
return v1 == v2 -- no longer an error
end
Table value type propagation now correctly works with [any] key type:
--!strict
type X = {[any]: string | boolean}
local x: X = { key = "str" } -- no longer gives an incorrect error
If a generic function doesn’t provide type annotations for all arguments and the return value, additional generic type parameters might be added automatically:
-- previously it was foo<T>, now it's foo<T, b>, because the second argument is also generic
function foo<T>(x: T, y) end
We have also fixed various issues that have caused crashes, with many of them coming from your bug reports.
Autocomplete improvements
Studio autocomplete has received a few improvements:
- Function argument names have been added to the function signature display
-
Instance:GetAttributeandInstance:SetAttributewill now suggest attribute names if instance can be resolved - Inside the new if-then-else expression, incorrect suggestions following
elsehave been fixed - Deprecated lowercase
Color3:toHSVso it’s no longer suggested - Deprecated lowercase
Instance:findFirstChild,Instance:clone,Instance:remove,Instance:getChildrenand old alias calledInstance:children.
Linter improvements
GlobalUsedAsLocal lint warning has been extended to notice when global variable writes always happen before their use in a local scope, suggesting that they can be replaced with a local variable:
function bar()
foo = 6 -- Global 'foo' is never read before being written. Consider changing it to local
return foo
end
function baz()
foo = 10
return foo
end
Performance improvements
Garbage collection CPU utilization has been tuned to further reduce frame time spikes of individual collection steps and to bring different GC stages to the same level of CPU utilization.
Returning a type-cast local ( return a :: type ) as well as returning multiple local variables ( return a, b, c ) is now a little bit more efficient.
Function inlining and loop unrolling
In the open-source release of Luau, when optimization level 2 is enabled, compiler will now perform function inlining and loop unrolling.
Only loops with loop bounds known at compile time, such as for i=1,4 do , can be unrolled. The loop body must be simple enough for the optimization to be profitable; compiler uses heuristics to estimate the performance benefit and automatically decide if unrolling should be performed.
Only local functions (defined either as local function foo or local foo = function ) can be inlined. The function body must be simple enough for the optimization to be profitable; compiler uses heuristics to estimate the performance benefit and automatically decide if each call to the function should be inlined instead. Additionally, recursive invocations of a function can’t be inlined at this time, and inlining is completely disabled for modules that use getfenv / setfenv functions.
This optimization should be enabled in live Roblox experiences soon™.
yeah not a bad idea, although a bit ugly
We specifically made sure that they don’t need to be used when iterating over tables or array-like tables.