lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Mar 1, 2020 at 9:28 AM Anton Jordaan <anton.jordaan@sylvean.com> wrote:> Coda Highland wrote:
>> This comes up very, very frequently.
>>
>> This is absolutely a non-starter for inclusion in stock Lua, but for
>> your own programs there are a number of solutions that have been
>> proposed and/or implemented.
Could you elaborate why this is a non-starter?

I have seen a number of solutions (including solutions that use
metatables to define dynamic arrays, which are useful only when
assigning) and also offered my own preferred code examples,
which manage do the job in my own programs, but none of these
workarounds are as simple -- and consistent -- as writing v =
t[a][b][c][d][e].

For read-only use, nil[k] == nil isn't TOO awful, and if the language had been designed that way from the beginning it would probably have been okay. Unfortunately, plenty of existing code depends on the current behavior so it's far, far too late into Lua's existence to be making that change. It would break too many things to convert a meaningful runtime error into something silent, especially when there are alternatives (such as the get() function I demonstrated) that can achieve the same goal without breaking anything.

For automatically creating a hierarchy of tables, on the other hand... The realistic use cases where this would be the best syntax without any drawbacks are fairly few. It would require a more invasive patch to Lua to accomplish it for something that isn't super commonly applicable in practice -- for most programs, you're not going to be making a deep assignment into an arbitrary possibly-undefined table hierarchy. And enabling this kind of behavior by default can not only mask errors, it can also really break things if your data type has certain expectations for how things are supposed to be assembled. Again, there are other ways of achieving the goal that have fewer drawbacks, so doing it in the core just doesn't really make sense.

/s/ Adam