 |
lua-l archive |
|
|
||
|
On 8/17/2016 5:50 PM, Vaughan McAlley wrote:
On 18 August 2016 at 07:14, Ross Berteig <Ross@cheshireeng.com> wrote:But note that it is possible to construct a table in such a way that it has only integer keys, and yet nearly all are still stored in the hash table and not in the efficient array part. A lot of effort has gone towards making such a pathological case difficult to achieve, but there is nothing in the spec that forbids that. Such a table would iterate keys in a completely arbitrary order with lua_next().Would it be reasonable to assume you will be OK if you don’t construct the array part of your table “pathologically”?
Nope. The "array part" is an implementation detail. If it happens to be used, it will be iterated first, but you cannot assume that it either exists or will be used. It is not part of the specification of a table.
The next version of Lua could choose to iterate the array part in reverse order or after the hashed keys and, while either would be surprising, it would not be a bug because nothing requires either that there be an array part or that it be iterated in a particular direction or at a particular time. Your only guarantee is that lua_next() will make a complete pass through all the keys.
Yes, you will probably get away with it. Until you ship the code somewhere it can't be easily fixed, or your reputation depends on it behaving, or Murphy's Law catches up to you.
Honestly, the cost of writing a loop over integers from 1 to #t is so low (even in C) that you should just do that rather than assume that an undocumented behavior will work under all conditions.
-- Ross Berteig Ross@CheshireEng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602