[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua Unpack with nil inconsistent behavior
- From: Andrew Gierth <andrew@...>
- Date: Sun, 16 Jul 2023 09:39:48 +0100
>>>>> "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.