[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: tostring() and the "not even nil" type.
- From: HyperHacker <hyperhacker@...>
- Date: Thu, 29 Apr 2010 22:03:54 -0600
Probably the same should be done for tonumber() and type(). Though,
maybe a better solution is to just use pcall() or extra parentheses
when you have reason to suspect this will happen.
On Thu, Apr 29, 2010 at 21:03, WU Jun <quark@lihdd.net> wrote:
> In lua source code, there is a LUA_TNONE type.
> It is different from LUA_TNIL.
>
> LUA_TNONE is useful in C API, when trying to get a value type exceeding a
> valid stack range, LUA_TNONE is got.
>
> I think tostring() can regard LUA_TNONE as LUA_TNIL.
>
> On 04/30/2010 03:31 AM, Pierre-Yves Gérardy wrote:
>>>
>>> a=function()end
>>> = tostring(a()) --> Error.
>>> = tostring(select(2)) --> Ditto.
>>
>> tostring() throws an error when it doesn't receive any argument. Since
>> it is often called to sanitize a result before concatenation, it could
>> make sense if it returned "nil", or even the empty string instead.
>>
>> In most other circumstances, these "lack of value" are converted to
>> nil, but not here.
>>
>> A partial solution is to append "or nil" to the argument of every
>> risky tostring() call, but it would be more elegant if it were handled
>> at the language level.
>>
>> -- Pierre-Yves
>>
>
>
--
Sent from my toaster.