Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Andrew Starks <andrew@...>]

On Thu, Jun 23, 2016 at 06:48 Viacheslav Usov <via.usov@gmail.com> wrote:

On Thu, Jun 23, 2016 at 1:31 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> I'd interpret your results a little differently: select is clearly preferential perf-wise for one or two arguments, then just use {...}.

Which suggests two further points.

1. (More important) The reference manual should point out that {...} is the best way, overall, to deal with variadic arguments, and select is deprecated. This brings us back to the original topic.

2. (Less important) It would be nice to have a way to determine the number of variadic arguments without calling any function, something like #... as already suggested. Then a variadic function could, in principle, choose an optimal way to handle any number of arguments.

Cheers,

V.

If variadic arguments are limited to their most obvious use case, then is that actually necessary?

Using them as data structures seems akin to using a butter knife as a screw driver. It's trivial to make an ordered list with nils, using a table.

The benchmarks thus far have told me that at best you might see a small gain and you'll almost certainly make the program harder to follow.

Using them as intended, to provide a variable number of arguments to a function, requires no change in the documentation.

-Andrew