Re: [ANN] Lua 5.4.0 (work1) now available

[Paul K <paul@...>]

>> Why is the new "undef" not used the other way round:
>>
>> A[2] = nil removes the entry from the table
>> A[2] = undef  puts a value in A[2] that reads 'nil'
>>
>> That would keep compatibility with Lua 5.3 and older
>
> We thought about something like that.
>
> The problem is neither 'a[t]=nil' nor 'a[t]=undef', but 'a[t]=x' when
> 'x' happens to be nil. This is what creates surreptitious holes in
> tables that leads to all the problems with '#t'. In the end, we would
> have something like this:
>
> x = nil; t[1] = x;    -- adds element
>          t[1] = nil;  -- remove element

I interpreter Oliver's proposal differently: in both cases the element
would be removed (the same behavior as with the current version of
Lua).

Only `t[1] = undef` will add `nil` without creating a hole (empty
value). So, you'd need to be explicit by using "undef" when you want
to remove the element, but keep its spot in the table and not when you
simply want to remove the element (as it is in the current undef
proposal). You don't need a new compile switch, as the behavior in the
new version is the same as in the current version unless `undef` is
used.

I also find this approach more consistent and easier to explain
(assuming I got it right).

Paul.