tables, table.unpack and nil values

[Phanx]

Honestly I can't even think of any scenario where it would even be useful or desirable to store nil values in a table.

If you're removing a value from an indexed table (array), and need to preserve the original indices of the other values for some reason, just set the value to false or -- if you're already using booleans for something else -- a custom string like "nil", or a number like -1, or some other value that is obviously different from the "real" values in the array that you can consistently assume means "there is not a real value at this index".

[Billtopia]

my from what I read above they were looking for a way to append more items to a table without breaking the ability of things like unpack to properly handle them. no known method exists for getting the last index if the last index is nil... table.maxn() would give the highest non nil index where #table will give (in most cases) the index before the 1st nil... if only we could get blizz to return falses instead of nils then they wouldn't be having these problems. does the n = ## still work in the table assignments? if everyone did that then # would return (or is supposed to) return n and then they could append to the table with no real problems

[Phanx]

Yes, but how are the nils getting into your table in the first place, and why do you want to keep them there? I would argue that any code that's putting nil values in the middle of an indexed table is poorly written and/or poorly thought-out, and should be rewritten. If you're doing it because you want to explore the inner workings of the Lua programming language and/or Blizzard's implementation of Lua in WoW, go for it, but there's just no reason I can think of to do anything like this in real code that you intend for anyone to actually use for a practical purpose.