Re: Quest: real world "Lua array with holes" usage

[Hisham <h@...>]

On 21 July 2016 at 14:58, Jorge <xxopxe@gmail.com> wrote:
>
>
> On 21/07/16 14:09, Roberto Ierusalimschy wrote:
>>
>> The only real-world case that bothers me is when you want to collect all
>> the results from a function call, something like {f()}. If there is an
>> error, the standard protocol is to return (nil, msg), which would create an
>> array with holes.
>
> Yes, that's the only way I get holes in arrays. OTOH, that's happening a lot
> less since I decided to assert  all functions that can return nil,... unless
> I specifically know what to do in that case. Anyway, it's pretty easy to
> check ret[1]==nil to see if the call was successful.
>
>> (Currently I think the correct way to fix this would be to return (false,
>> msg), not to change the behavior of lists.) -- Roberto
>
> I have doubts on this, because false is a reasonable value to get from a
> function... Returning nil is clearer because the meaning is "could not
> produce a value to return". Otherwise you end using a explicit return for
> status pcall-like, all the time.

I agree with Jorge. Also, sometimes when returning multiple things,
one of these things might be nil, so it's not only the error situation
that produces a nil value upon return, although it is of course the
most common. So, unfortunately just changing the policy from
nil-on-error to false-on-error still wouldn't allow us to just forget
about table.pack().

-- Hisham