[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.4.0 (work1) now available
- From: Dirk Laurie <dirk.laurie@...>
- Date: Wed, 14 Mar 2018 15:14:25 +0200
2018-03-14 14:46 GMT+02:00 pocomane <pocomane_7a@pocomane.com>:
> Some opinions about undef. Right now, nil is needed for:
> 1) skip some arguments or return values in a function call
> 2) check presence in tables or remove something from them
> 3) Other ?
>
> IMHO, the mixed solution (nil/value for 1 while undef/keyword for 2) is very
> little lua-ish. It is complex and difficult to explain, also if it just adds an
> handfuill of exception to care of. This because both 1 and 2 in our human mind
> are recognized to model the same thing: something "Missing".
>
> I am not saying that undef should be removed as a test feature. On the
> contrary, it would be nice to have the possibility to play with a full solution
> that works also for 1. I also theoretically prefer "Keyword/no-value" semantic.
> But I really do not see any simple way to keep this semantic in 1.
>
> I mean: if I can pass something to a function, and I can get it back from a
> call... well it is a value!
If you enable LUA_NILINTABLES (as explain in detail in a new thread),
there is another value of type nil, call it 'empty'. You can't tell
the difference between the values 'nil' and 'empty' at the level of
the API, let alone in Lua.
But for the sake of the argument, suppose you could. When you say
"t[4]=nil", what really happens is the equivalent of
"rawset(t,4,empty)", and when you say "t[4]=undef", what really
happens is the equivalent of "rawset(t,4,nil)".
At the level where '#' is calculated, 'empty' is distinct from 'nil'
and so the table does not have a hole there.
[1] Nils in tables in Lua 5.4.0 (worki1) (Was: [ANN] ...now available