Re: unpack behaviour in 5.1

["Brad Jorsch (Anomie)" <bjorsch@...>]

On Mon, Jul 1, 2013 at 7:15 AM, Finn Wilcox <finnw@finnw.me.uk> wrote:
>
> On 01/07/2013 12:10, Mark Melling wrote:
>>
>> At least from my perspective unpack seems to behave strangely when
>> dealing with nils - as you can see from the output below.
>>
>> Is this expected behaviour?
>>
> Yes.

As to why: the defaults positions for unpack are 1 and "the length of
the list, as defined by the length operator". And the length of the
list is not uniquely defined if your list "contains" nils: it's valid
in 5.1 for #{nil,2,nil} to return either 0 or 2 (see
http://www.lua.org/manual/5.1/manual.html#2.5.5 for further
explanation). And in your test it happens to choose 0 for {nil,2,nil}
and the not-zero option for {nil,2} and {nil,2,3,nil}.

Note that in 5.2 the behavior of the length operator for non-sequence
tables is even less constrained.

>> How can I get unpack({nil,2,nil}) to return nil,2?
>
> print(unpack({nil,2,nil},1,2))

This works, of course, because it is explicitly specifying the ending
position. So no list operator uncertainty is involved.