 |
lua-l archive |
|
|
||
|
On 29/10/2011 12.07, Andrew Scott wrote:
I was working on some code that involved copying indexed tables, and noticed that copying an indexed table T1 that was missing a [1] key (so that #T1 == 0) yielded a table T2 that would return the length as if the [1] key were in T2. Below is the simplest code that I could get to reproduce this. Removing any of the keys 2, 3, or 4 from T1 makes both tables return a size of 0, but adding additional keys after 4 to T1 simply causes T2 to reflect the new highest key.
[...]
I don’t know why any of this is happening, but it seems extremely buggy to me. Why are my tables that are missing a [1] key returning a size? ipairs() will not traverse them, but (for i=1, #table) will? This should not be.
The length operator '#' returns the intuitively-correct value only for tables which are "arrays" ("sequences", in the new Lua 5.2 parlance), i.e. tables whose numeric keys begins at 1 and ends at some other integer N. If there are "holes" or non integer numeric keys, '#' returns weird values, although its behaviour is well-defined in the manual [1] (this behaviour was criticized and lead Lua Team to remove the definition of '#' for non-sequences in 5.2 and clarify the concept of "array", now formally called "sequences" in the manual [2]).
The same applies to ipairs (it will traverse an array only if *it is* an "array") and almost all other table library functions.
[1] http://www.lua.org/manual/5.1/manual.html#2.5.5 [2] http://www.lua.org/work/doc/manual.html#3.4.6