Nick already doesn't actually use the table key for anything. The pairs iterator will work for a non-keyed table too so you don't have to do anything and can just use Nick's example directly. If it makes you feel better about the code, you can change "pairs" to "ipairs". It will most likely do exactly the same* thing for your case, but will be semantically more correct.
This peers into one of the more interesting aspects of Lua language, which is that tables are a melange of both key-value dictionaries and ordered-value lists, and you can mix the two into the same table, because really all non-keyed table entries are just automatically given numeric keys.
Try doing each of the following in a Lua script and see how the results differ:
-- using pairs
> for k,v in pairs({"hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
> for k,v in pairs({["3"]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
3 foo
-- 1 and "1" are different types, so both get put into the table
> for k,v in pairs({["1"]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
1 foo
-- using ipairs
-- "1" is ignored, because it's not a number and ipairs only does numbered entries
> for k,v in ipairs({["1"]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
> for k,v in ipairs({[3]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
3 foo
-- 1="foo" gets overruled by "hello" being the first non-keyed value, because the latter takes priority
> for k,v in ipairs({[1]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
-- ipairs stops at the first gap in numbers
-- since there is no 3, it never sees 4
> for k,v in ipairs({[4]="foo", "hello", "goodbye"}) do print(k,v) end
1 hello
2 goodbye
* - I think there may be some small risk that using pairs instead of ipairs on a non-keyed table could potentially return the results out of order, though? Not sure how real that memory is. |