Re: ipairs parameters

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

2016-06-21 0:40 GMT+02:00 Thijs Schreijer <thijs@thijsschreijer.nl>:
>
>> 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.

I've missed it most in table.sort. table.unpack and table.pack both
have it, so the omission in that case is not orthogonal.