I'm not sure an
intangible second class value to represent a concept is the lua way either. The only reason it exists is due to the way the C API retreives arguments from the stack. Without select, which is a C function, there would not even be a way to check this in lua. Eliminating it would arguably be more minimalistic? There's always been a discontinuity with arguments, a lua function which binds 1 argument to a parameter can be called with f() and f(nil) indistinguishably (without using C functions to check) which is not the case for C function calls.
Op Do. 7 Mrt. 2019 om 07:49 het Egor Skriptunoff
<egor.skriptunoff@gmail.com> geskryf:
>
> On Thu, Mar 7, 2019 at 6:26 AM sur-behoffski wrote:
>>
>>
>> Section 2.2 of my 5.1 manual states:
>>
>> [...]
>>
>> There are 8 basic types in Lua: nil, boolean, number, string
>> function, userdata, thread and table.
>>
>> Nil is the type of the value nil, whose main property is to be
>> different from any other value; it usually represents the
>> absence of a useful value.
>>
>> [...]
>>
>> Typing in that portion of the manual by hand, I tend to feel that
>> there is tension between an "implicit nil" and an "explicit nil",
>> with "implicit nil" possibly being the best description for:
>>
>> tostring(f())
>>
>> Another name for "implicit nil" might be "none", which links into the
>> discussion thread descriptions and the C API. You could even split
>> "none" into two variants (the naming here is awkward, sorry):
>> In other words,
>> none-that-will-coerce-to-nil-upon-evaluation
>> none-that-cannot-be-coerced-to-nil
>>
>
> Exactly!
> For some strange reason, Lua is not conceptually clear about nil.
> Nil is defined as absence of value.
> And this definition works well with Lua tables (all absent keys have value nil).
> This definition works well also with multiple assignment in Lua.
> But tuples in Lua are inconsistent with the definition of nil.
> IMO, any tuple of values should be think of as padded by nils to infinity.
> There should not be any difference between the following statements:
> return
> return nil
> return nil, nil
> Neither in Lua, nor in C API a user should be able to distinguish between LUA_TNONE and LUA_TNIL.
That would dictate policy. It's not the Lua way.
Instead, recommend that programmers should not lazily `return` when
they mean `return nil`.
