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

[Jorge <xxopxe@...>]

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 believe the main problem with nil in arrays stems not from the 
language, but from the design of programs: there is a tendency to use 
nil for nil-like concepts in the business logic, and that's when things 
get broken. A database NULL is not nil, is a singleton {}. The same for 
"free_slot", "nodataacquired" and whatever. Nil should be reserver for 
language-level concepts, like "the function failed to get a result" or 
"this variable has no value assigned".


Jorge