Support Variadic Generic For Loops

Feature Requests Engine Features
1

Summary

Add support for variadic loop variables in generic for loops, allowing developers to capture and forward an arbitrary number of values returned by an iterator.

Motivation

Currently, generic for loops require all loop variables to be explicitly declared:

for a, b, c, d, e in iterator() do
	Process(a, b, c, d, e)
end

This becomes cumbersome when writing generic wrappers, networking systems, event dispatchers, or utility libraries where the number of returned values may vary or is intentionally abstracted.

Developers often only want to forward all returned values without caring about the exact count.

I recently ran into this situation while working on my framework, RoExpress. Several systems expose iterators that may return varying numbers of values depending on the underlying implementation. In some cases I only wanted to pass the iterator results directly into another function, but I was forced to explicitly name every possible return value even when those values were never used individually.

This led to unnecessary boilerplate and reduced the flexibility of otherwise generic code.

Proposed Syntax

for ... in iterator() do
	Process(...)
end

Potentially:

for key, ... in iterator() do
	Process(key, ...)
end

Example Use Cases

Event Forwarding

for ... in EventIterator() do
	Dispatch(...)
end

Network Message Routing

for player, ... in Network:GetMessages() do
	Handle(player, ...)
end

Generic Wrappers

for ... in source() do
	target(...)
end

Benefits

  • Reduces boilerplate.
  • Improves readability.
  • Makes generic utility code easier to write.
  • Better supports APIs that intentionally return variable-length tuples.
  • Aligns well with Lua’s existing variadic function capabilities.
  • Particularly useful for framework authors and library developers creating generic abstractions.

Considerations

A variadic loop variable would need clear rules regarding:

  • Whether mixing named variables and ... is allowed.
  • How tuple packing/unpacking should behave internally.
  • Performance implications compared to fixed loop variables.

If full variadic support is undesirable, an alternative could be exposing the iterator’s return tuple as a packed table or tuple object.

Conclusion

Luau already has strong support for variadic functions through .... Extending that concept to generic for loops would make iterator-based code more expressive and reduce unnecessary boilerplate in advanced systems such as networking, event pipelines, framework development, and generic abstractions.

As someone building a framework (RoExpress), I have encountered multiple scenarios where iterator results needed to be forwarded without knowing or caring about the exact number of returned values. Supporting variadic generic for loops would provide a cleaner and more natural solution for these use cases.

2 Likes
2

Also for side note even though i could just returned a packed table

for packed in Iterator() do 
   packed.Somevar1 +=10
   packed.Somevar2 -= 10
end

The Cons are outweighed by its pros

  • Cons: High overhead. It requires allocating a new table array {...} on every single iteration step, triggering frequent garbage collection (GC) cycles.
  • Complexity: O(n) memory allocations where ƞ is the number of iterations.
    this requires table manipulation with can affect performance
1 Like
3

submit a rfc, don’t put luau addition requests here

2 Likes