Re: Upcoming changes in Lua 5.4

[Paige DePol <lual@...>]

Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:

> And I have wonderful idea how to solve this problem.
>  
> The idea: At compile time (prior to building bytecode) a function body 
> is searched for "non-read" access to _ARG... [snip]


Paige DePol <lual@serfnet.org> wrote:

> The compiler could create a "static vargs" flag for functions which only
> pass on the varg parameters without accessing or modifying the parameters.
> In such cases the vargs could just be treated as they were in previous
> versions of Lua, and thus would only be converted into a table at the
> point of the forwarded function call.

This is fairly similar to my idea earlier in this same thread!

Though, an extra opcode probably isn't required. Either the vargs will be
wrapped up in a table, or they will be static and can just be read off the
stack. So, either <=5.3 behaviour or 5.4+ behaviour depending on context.

Given the two usage types for vargs it might be worthwhile to create a new
data type to represent them. This data type could then use an internal flag
that indicates if the vargs are still on the stack, or if they have been
moved into a table. Either way the syntax for vargs could be the same, and
it just becomes an implementation detail.

Also instead of using ".n" to get the number of vargs #... could be used
instead which, in my opinion, looks nicer. If ... was simply made into a
new data type then we wouldn't need the "...=table" function declaration
either and could just use ...[1] or #... style syntax regardless of how
the vargs themselves are being stored.

I feel like tinkering with the 5.4 GitHub code to see how viable these
ideas may be... but I already have a list of things to work on already!

~Paige