Re: Issues with the current varargs implementation (Was: Re: inadequate documentation for select and table.unpack)

[Hisham <h@...>]

On 21 June 2016 at 20:45, Soni L. <fakedme@gmail.com> wrote:
>
>
> On 21/06/16 08:43 PM, Nagaev Boris wrote:
>>
>> On Tue, Jun 21, 2016 at 11:17 PM, Soni L. <fakedme@gmail.com> wrote:
>>>
>>>
>>> On 21/06/16 05:15 PM, Patrick Donnelly wrote:
>>>>
>>>> On Tue, Jun 21, 2016 at 3:59 PM, Sean Conner <sean@conman.org> wrote:
>>>>>
>>>>> It was thus said that the Great Patrick Donnelly once stated:
>>>>>>
>>>>>> On Tue, Jun 21, 2016 at 3:22 PM, Soni L. <fakedme@gmail.com> wrote:
>>>>>>>
>>>>>>> But varargs (and thus varargs-based arrays) are nil-safe by default.
>>>>>>
>>>>>> Show me in the manual where it says **tables** are not nil safe and
>>>>>> I'll stop posting to lua-l*.
>>>>>
>>>>>     Lua 5.3, section 3.4.7:
>>>>>
>>>>>           Unless a __len metamethod is given, the length of a table t
>>>>> is
>>>>> only
>>>>>           defined if the table is a sequence, that is, the set of its
>>>>> positive
>>>>>           numeric keys is equal to {1..n} for some non-negative integer
>>>>> n.
>>>>> In
>>>>>           that case, n is its length. Note that a table like
>>>>>
>>>>>                {10, 20, nil, 40}
>>>>>
>>>>>           is not a sequence, because it has the key 4 but does not have
>>>>> the
>>>>>           key 3.  (So, there is no n such that the set {1..n} is equal
>>>>> to
>>>>> the
>>>>>           set of positive numeric keys of that table.) Note, however,
>>>>> that
>>>>>           non-numeric keys do not interfere with whether a table is a
>>>>>           sequence.
>>>>>
>>>>>     But for this discussion:
>>>>>
>>>>> function foo(...) print(select('#',...) end
>>>>> function bar(t)   print(#t)             end
>>>>>
>>>>> foo(1,2,3,4)
>>>>> 4
>>>>> bar{1,2,3,4}
>>>>> 4
>>>>> foo(nil,nil,3,nil)
>>>>> 4
>>>>> bar{nil,nil,3,nil}
>>>>> 0
>>>>
>>>> There's an echo in this room. Apparently emphasizing **tables** is
>>>> lost on people so let me be crystal clear: table length is only
>>>> defined for sequences. __So__, while sequences are not nil-safe, that
>>>> does __not__ mean tables are not nil-safe.
>>>>
>>> Thus, tables are not suitable as proper arrays.
>>
>> Why do you want to put nil into a proper array? For me, a proper array
>> is an array of elements of same type, e.g. array of integers. If some
>> element in an array is nil (and other are not nil), there is no single
>> type for all elements, so it is not a proper array.
>
> For me, a proper array in Lua would be an array of pointers. This inculdes
> nil aka null pointers.

Lua has no pointers. Nil is not a null pointer. You are not thinking
in Lua, you are thinking in C or some other language.

-- Hisham