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

[albertmcchan <albertmcchan@...>]

On Mar 14, 2018, at 2:12 PM, Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great albertmcchan once stated:
>> 
>> what is so bad about the old syntax x = nil ?
>> 
>> false were added in lua to "store" nil in table, there is no need for undef.
>> 
>> I am curious, is there an example where undef is truly needed ?
> 
>  Assume you have the following JSON:
> 
>    [ 1 , 2 , true , false , nil , "alpha" , "beta" ]
> 
>  Under the current (5.3) behavior, you can convert this to the following
> Lua table:
> 
>    { 1 , 2 , true , false , nil , "alpha" , "beta" }
> 
> but the length is undefined, because the nil creates a hole.  If you use
> false instead:
> 
>    { 1 , 2 , true , false , false , "alpha" , "beta" }
> 
> the length *is* defined, but it may not have the same semantic meaning. 
> Now, with the proposed undef (which seems to be confusing a lot of people),
> the Lua table:
> 
>    { 1 , 2 , true , false , nil , "alpha" , "beta" }
> 
> would have a defined length and semantically matches the original JSON.
> 
>  -spc
> 
> 

If you really want a table without holes, just use false for nil in table.
Your example have BOTH false and nil, that meant you wanted the hole.

Yes, "new" syntax undef can fill holes, but it can also make holes.

All it does is shift the name for nil. Now, undef does the work of nil.

Once, this shifting names of nil started, it will never end.
Say, add undef2 so that undef can store in table, undef3 for undef2 ...

You can argue we will never add keyword undef2 to allow undef in table.
But, is that what the "new" undef does to allow nil in table ?