Re: Lua 5.4-work1 with first class arrays (implementation & benchmarks)

[Paul K <paul@...>]

Hi Petri,

> Again, I’ve not found any (measurable) performance cost with regular tables caused by the patch. But you don’t need to just take my word on it, please do run some tests yourself, the code is there in github.

I like the idea, the implementation, and the result, but am a bit
uneasy about the new array syntax.

Would it be better to allow table.resize to accept a regular table and
convert it into an array? This still has all the benefits of arrays,
but is fully (syntactically) compatible with earlier versions. In this
case only the array part would be affected by the changes and the
tables could still include the hash part (as it's not going to be
affected by the fixed size of the array part). In fact, this is
largely what `luaH_resizearray` does (minus inserting elements from
the hash part). If `resize` is allowed to work this way, it would also
be convenient to return the table itself, so it can be used in `return
table.resize({...}, select('#', ...))` or `local t = table.resize({},
10)` expressions. It may also be useful to allow the length to be set
based on .n field or the current # value: `return
table.resize(table.pack(...), true)` (where `true` would indicate
auto-size).

I wonder if there has to be a way to tell if `resize` has already been
used or not on a particular table. Maybe `resize` has to return the
size of the array part as its second parameter or `nil` for regular
tables?

Paul.