Re: #{...}

[Adrian Sietsma <adrian_groups@...>]

David Given wrote:
> Adrian Sietsma wrote:
>
> > I note that #{nil,1,2,3} returns 4, in Lua 5.1. This behavior is highly
> > desirable, but contradicts the 5.1 documentation re #. Can this
> > behaviour be relied upon (otherwise unpack({...}) would lose embedded
> > nils) ?
>
>
> No; by using an array with a nil in it, you're breaking the rules, and
> you're open for all kinds of undefined behaviour.
I know, but this is the special case of a list constructor, not an inserted nil.
> I believe this also applies to unpack({...}), assuming that ... is
> syntactic and not shorthand for 'insert stuff here'. If the ... expands to
> a tuple containing a nil, Bad Stuff will happen.
That is how i read the docs; however it makes a _huge_ difference; if it can
 be assumed that unpack({...}) == ..., (for both the ... object, or any
arbitrary list) then the following constructs are valid :

function f()
   local t = {a_function_call()}
--do stuff
  return unpack(t)
end

and
function f1(...)
  x.args = {...}
end
function f2()
  f3(unpack(x.args))
end

To be correct according to the docs, I should be doing
unpack(t,1,table.maxn(t)), which is ugly.

So : I like the behaviour as it is; can I rely on it for the life of 5.1 at
least? Otherwise, could unpack() default to maxn ?

Adrian