Re: Unexpected error using tostring

[Dirk Laurie <dirk.laurie@...>]

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`.