Re: [ANN] Lua 5.2.0 (work1) now available

[Ted Unangst <ted.unangst@...>]

On Thu, Jan 14, 2010 at 8:07 PM, Doug Rogers
<doug.rogers@elbitsystems-us.com> wrote:
> Klaus Ripke wrote:
>> I fail to see how breaking perfectly valid code
>> by trading a well defined behaviour for all tables
>> for something undefined on "arrays with holes" does any good.
>
> Agreed. The only reason #t has its undefined behavior is because it is
> impractical for it to iterate the table. But the whole point of ipairs()
> is to iterate the table - it is already doing that! So I prefer the
> previous behavior - iterate until nil.

Being somewhat new to Lua, could someone explain a case where this
really matters?

I generally treat tables as hash tables (and don't use ipairs), or
treat them as dense unholed arrays.  Maybe I will have a table that's
both, with both int and string keys, but the int part is still dense.

I'm having trouble thinking of a case where you would have a dense
array part that you want to iterate on, but then "somewhere else" use
int keys as a hash.  What would you do if the dense part grew?