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

[Petri Häkkinen <petrih3@...>]

> On 30 Mar 2018, at 12.10, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> To sum up what I meant:
> - Add an array size field to all tables like you did in your patch.
> - Don't introduce a new array sub-type.
> - Add the array size update code to the table key insertion function (I believe there is already a separate code path for integer inserts).
> - Array literal syntax is optional (I wouldn't add it). But table literals should set the array size field to the largest integer key.
> - Add a `table.resize()` function like you did, and modify the other table functions to update the array size field. (You probably also need some new C API functions for setting the array size.)

It’s getting late and I’m about to hit the bed but here are my responses to the main points:

You didn’t specify how and where this size should be used but I’m guessing you mean that this size should be returned by # for normal Lua tables.

In that case you’d be changing the semantics of Lua tables and therefore potentially breaking existing code in subtle ways.

What the lua-array patch does is to add new semantics for arrays and leave the existing table semantics untouched to guarantee 100% compatibility with old programs.

> I think there will be broken code no matter which solution to the array problem we choose.

Nope, this is where you are mistaken. The main design goals of the array patch is to not break existing code and to not affect performance of tables. If you think that the array patch breaks an existing program, I’d want to know how.

Petri