[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Unexpected error using tostring
- From: Dirk Laurie <dirk.laurie@...>
- Date: Thu, 7 Mar 2019 07:57:42 +0200
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`.