Re: Strong tables in Lua 5.4

[Hisham <h@...>]

On 20 March 2018 at 10:27, Thomas Jericke <tjericke@indel.ch> wrote:
> On 19.03.2018 17:16, Hisham wrote:
>
>
> Every attempt of smoothing out the incompatibility ("strong tables",
> undef syntax hack, etc.), while well-intentioned, just adds terrible,
> terrible pitfalls to the language (e.g. "Of course you may not pass a
> strong table to old libraries").
>
> -- Hisham
>
> I assume you have read my post, as your example is an exact quote from my
> mail.
> If my assumption is correct. Can you please elaborate what is so terrible,
> terrible about it?
>
> Passing a "strong" table to a library that isn't able to cope with it will
> get you unpredictable results. That is not nice, but it is not too hard to
> avoid.
> There are similar problems with tables that have metatables already. You can
> actually implement a "strong" table with Lua 5.3 using metatables, therefore
> the damage has already been done.
>
> I actually still like to believe, that an opt-in solution (only those who
> need it must use it) is possible within the Lua 5 universe without the
> language having to take terrible, terrible damage.

First of all, I meant no offense. Lua (like every other language, I
guess) already has major pitfalls (#t being one of them). The pitfall
I was referring to would be the situation where something like {...}
creates a strong table in Lua 5.4+ and a normal table in Lua 5.3 and
below. _Fully opt-in_ strong tables, as you said, are doable in Lua
5.3 today already, and they would not cause terrible, terrible damage
at all, because their use would be explicit (like setting metatables).
As you said, those who need it, use it, and are aware of it.

But I when consider the proposal of strong tables, what I have in mind
is not only "nulls in JSON arrays" but the whole spectrum of problems
that -DLUA_NILINTABLE is aiming to solve, including things like {...}
and {f()} (i.e. the need for select()/table.pack()/table.unpack() in
the language). If constructs like this become strong tables by
default, then it will not fit the Lua 5 universe without bringing
hard-to-track compatibility issues.

(In short, I consider a source of hard-to-track compatibility issues
any proposal that requires a complete dependencies-deep code audit to
ensure that Lua 5.x code will remain working as intended without
introducing memory leaks.)

Each idea has pros and cons. Egor's proposal, keeping Lua 5 table
behavior by default but adding new syntax for tables that behave
differently, is an interesting one. Yes, it means that Lua 6 code
would not parse under Lua 5.x, but it would mean that all existing Lua
5 modules would run on Lua 6 the way their authors intended. Its major
con is that if {...#} means "pack all arguments into this table
including any nils" [1], then we'd get in a weird JavaScript-like
situation where "=== is the correct equality and == is the old one you
shouldn't use anymore but we can't take away", because {...#} would be
the one that "always works" (and {...} would become a pitfall in
itself).

-- Hisham

[1] via either Egor's original proposal of a user-settable length or
combining it with Dirk's proposal to make {...#} the strong-table
constructor