lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Got it. Thank you for the detailed explanation.

Milind

On Sun, Jul 16, 2023, 1:39 AM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "Milind" == Milind Gupta <milind.gupta@gmail.com> writes:

 Milind> Hello,
 Milind> I ran into this problem with table.unpack. I am using Lua 5.3.5
 Milind> and I see this:

 > Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
 >> t1 = {nil,"test"}
 >> t2 = {true,nil,"test"}
 >> table.remove(t2,1)
 > true
 >> table.unpack(t1)
 > nil     test
 >> table.unpack(t2)
 >>

 Milind> So specifically after removing the 1st element using
 Milind> table.remove

Remember that table.remove depends on the value of #list, which is
indeterminate for tables that are not sequences (and your example is not
a sequence).

It so happens that on 5.3.x the value of #t2 before the remove is 3, but
it could equally well have been 1.

The default for table.unpack also depends on the value of #list, and
after the remove, the value of #t2 happens to be 0 (it could equally
have been 2, but it's indeterminate which). So the unpack defaults to
table.unpack(t2,1,0) which of course returns 0 values.

 Milind> Is this expected behavior?

It's one of the possible expected behaviors.

 Milind> Are there any guidelines how to unpack an array with nil
 Milind> values?

Unpacking isn't the problem because you can and should use
table.unpack(t,i,j) to unpack a range of elements [i..j] from a table
that isn't a sequence. What you _can't_ do is use table.remove on a
non-sequence, since there's no way to make it not depend on #t. You can
however use table.move, provided you track the table length yourself.

--
Andrew.