[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: ipairs parameters
- From: Thijs Schreijer <thijs@...>
- Date: Mon, 20 Jun 2016 22:40:08 +0000
> On 20 Jun 2016, at 19:06, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> 2016-06-20 16:35 GMT+02:00 Thijs Schreijer <thijs@thijsschreijer.nl>:
>> If ipairs would accept start and end indices (like unpack for example) then
>> instead of;
>>
>> for i = 20, 30 do
>> local obj = list[i]
>>
>> -- do some stuff with obj
>>
>> end
>>
>> I could write;
>>
>> for i, obj in ipairs(list, 20, 30) do
>>
>> -- do some stuff with obj
>>
>> end
>>
>> Thoughts? (besides that I could write my own iterator and all the undefined
>> stuff for non-contignuous tables etc)
>
> Tampering with either the argument list or the return values of
> a standard function is perilous. It is better, if providing such
> functionality, to do it under another name.
>
> Suppose a working program that contains the line
>
> for k,v in ipairs(myfunc(x,y,z)) do
>
> where myfunc is a function that returns a table and two more values.
> The present behaviour silently discards the extra values.
>
> This modification will cause that program to malfunction.
>
> Moreover, if those two extra values happen to be numbers, the
> malfunction may show up only as inexplicable results that require
> hours of debugging time.
>
Indeed, a (very small) backward compatibility issue. But this same caveat is already present in many locations.