Implement Lua 5.5 style named variadic arguments #1059
Conversation
Lua 5.5 allows an identifier after a `...` to collect variadic arguments
into a table, this patch implements that for Teal by generating that
collection manually. Like so:
```teal
local function foo(...ints: integer)
local x: {integer} = ints
local y = select(2, ...) -- Note: ... is still usable
end
```
```lua
local function foo(...)local ints={...};
local x = ints
local y = select(2, ...)
end
```
The main part of this patch is unifying function generation between
anonymous, record, local, and global functions to handle this in a
central location.
The secondary part in `visitors.tl` ensures to callers of the function
that it is variadic, but in the body, the bound name is an array.
To achieve this, when parsing a "..." in an argument list followed by an
identifier, that identifier node is stored in the `name` field of the
"...".
|
Teal Playground URL: https://1059--teal-playground-preview.netlify.app |
|
Hi! I'm on vacation this week but I wanted to quickly jump in on the phone to give you some feedback: I like this idea a lot! I think this is one of the nicest Lua 5.5 features. I haven't made any measurements myself, but I think I read something to the effect that Lua 5.5 is smart about only generating an actual table in memory for a named variadic if needed. If that's the case, then the best thing would be to emit a different output when targeting 5.5. Maybe something to implement later? Thank you for this PR! |
|
Actually for Lua <= 5.4, you may want to use table.pack (with a type of
|
This is a nice feature from 5.5 that was pretty easy to implement, so figured I'd throw a patch out, see if people want it.
Lua 5.5 allows an identifier after a
...to collect variadic arguments into a table, this patch implements that for Teal by generating that collection manually. Like so:(Not sure if there's a "style guide" for generated code, should there be spaces around the "=" and before the "local"?)
More details in the commit message. One thing I'd like to suggest is maybe deprecating/removing "typename..." variadics in function types as they might be confusing with this syntax on the opposite side of the "...".