Re: [ANN] Lua 5.4.0 (work1) now available
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] Lua 5.4.0 (work1) now available
- From: Oliver Kroth <oliver.kroth@...>
- Date: 2018年3月14日 17:05:54 +0100
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
Rather strange...
-- Roberto
Not sure if I did understand;
using Lua5.3 semantics:
x = nil; t[1] = x; -- removes element
proposed new 'value' undef:
t[1] = nil; -- removes element, creates hole, reads nil
x = undef; t[1] = x; -- removes element, creates hole, reads nil
t[1] = undef; -- keeps element, no hole, reads nil
I have read that there are two subtypes being used; that may help here
as well:
nil = nil.remove
undef = nil.keep
t[1] = nil; -- removes element, creates hole, reads nil
x = undef; t[1] = x; -- stores nil.keep in x, assignment to t[1]
stores nil.keep, no hole, reads nil
t[1] = undef; -- keeps element, no hole, reads nil (is nil.keep)
Would that work ?
--
Oliver