lua-users home
lua-l archive

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

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.