lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

(Sorry if I'm a bit late to the party- went through a great big machine shuffle a while back and didn't re-add the Lua list to my newsgroups until now.)

I agree with Patrick here. However I'd go a little further and vote for no
'table.pack' at all. I agree it is useful in some cases and people write
something like that often (as does 'string.split', 'table.append',
'table.copy', ...). But I don't believe there is one-version-fits-all to
make it into a standard library. Furthermore, the asymmetry with
'table.unpack' [1] and bringing back the 'n' field policy does not look like
the best choice either. Personally, I'd rather see 'apairs' [2] becoming

I would agree that using an 'n' field is an odd about-face for Lua
after the changes in 5.0 -> 5.1. It would be easier to just return a
second value and allow the programmer to set his own convention.

I don't agree that table.pack is not useful enough for inclusion. It
is way too difficult to save the return values of a function without
creating a new table. Setting unnecessary standards is one thing,
making a common problem doable is another.

I don't really see the need for table.pack at all- what does it provide over {...} and select('#',...)?
Is the table that table.pack returns not a new table?

The table-argument-saving-in function that I'd like to see is the function that returns a table that is the equivalent of several tables in its argument concatenated. This, in the classic Lua fashion, would have several useful applications, including allowing the use of all results from multiple function calls with multiple returns (which can't be done with an ordinary table constructor as each consecutive function cuts the last one down to one return). For example:

function function_with_multiple_returns() return 1,2,3 end


Calling this function with the example table would return {1, 2, 3, 1, 2, 3, 1, 2, 3}.