Fwd: Nils in tables in Lua 5.4.0 (worki1) (Was: [ANN] ...now available

[Hisham <h@...>]

Roberto,

For some reason the "From:" address changed in my message and the
email didn't go through the list, sorry. I did reply right away with a
real-world example. Follows below.

-- Hisham

---------- Forwarded message ----------
Date: 15 March 2018 at 20:22
Subject: Re: Nils in tables in Lua 5.4.0 (worki1) (Was: [ANN] ...now available
To: Lua mailing list <lua-l@lists.lua.org>


On Thu, Mar 15, 2018, 15:59 Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > I do value a lot the possibility of being able to keep writing code
> > that's "5.1 and up" compatible (LuaRocks is like that!). But I'd
> > prefer to have a syntax that doesn't work at all on 5.1-5.3 than to
> > have 5.4 code that runs on 5.3 (and vice-versa) but then silently
> > behaves differently.
>
> I don't see how 't[i]=undef' would behave differently with the new or
> the old semantics. What will behave differently is 't[i]=nil' (after
> all, this is the whole point of the change in the behavior), which
> we should avoid.


#t will silently work differently. But the point is that Lua code
doesn't live in a bubble. When I write Lua 5.3 code in a "Lua 5.1 and
up" fashion I assume that I have access to the entire Lua 5.x
ecosystem (from LuaFileSystem onwards). This has been true from 5.1 up
to 5.3.

Up until 5.3, writing code "5.1 and up" simply meant "do not depend on
the latest version's features": no `goto`s, the occasional `if`
statement to switch between `setfenv` and `_ENV`, a little wrapper to
normalize the return values of `os.execute`, that kind of thing. It
was never the case that "you can run code written for Lua 5.(x-1), but
it'll be broken in subtle ways".

If the clever "backwards compatibility" of undef means that I can
write Lua 5.4 code that runs on 5.3... as long as it doesn't make use
of the distinctive 5.4 features (fine) _and never interacts with any
Lua 5.1-5.3 code_ (not fine), then that's of very little use. And
making it look syntactically like it's "Lua 5.1 and up" compatible in
the sense that we've taken it to mean until today is bound to trip
people up (really not fine).

The bottom line is: if these two worlds of code (Lua 5.4 code with
undef and the vast ecosystem of thousands of existing Lua 5.x modules)
will never be able to integrate properly anyway, then it's better to
break the syntax to make sure people never try to run them at the same
time.

> > [...] if anywhere you forget and "unset" a key with nil (which you
> > can do indirectly, e.g. with table.move(), so no, grepping the sources
> > isn't enough), [...]
>
> Just for curiosity, can you give me a real-case example of unseting a
> key with nil indirectly through table.move?

https://github.com/titan-lang/titan/blob/foreign/c-parser/cpp.lua#L451

Anyway, I just gave that one example because I had it from the top of
my head. But it's trivial to think up other realistic examples. Take
any assignment of the form `t[k] = f()` where function f may or may
not return a value. Saying that such a drastic change would be
greppable is understating the problem by a huge amount.

-- Hisham