Re: A proposal for the confusing pseudo table ≈ array concept

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

My two cents...

I think this discussion is again about tables with holes and the # operator which have been discussed a lot in the past. 

I’ve written several hundred thousand lines of Lua code over the past 10 years or so, and in my experience tables with holes are very rare. In those few rare cases I’ve had them, it has been no problem to have an extra ’n’ field. In fact, I have a wrapper module for arrays (similar to what has been mentioned earlier in this thread) but I think I’ve only used it a couple of times over the years.

Some pros/cons of having a separate array type in my opinion:

+ possibly more efficient implementation

+ it would be possible to have out of bounds checking, but unclear if they should be errors or behave more like tables (return nil on read and extend the array on write)?

- new type => more complex language and implementation

- more complex C bindings, most C modules should work with both tables and arrays for conveniency?

- converting between tables and arrays, probably not very common, but would still have a cost when needed

- arrays would not have hash part, so can’t add extra info to them in named fields (pretty common thing in Lua I think)

Best regards,

Petri