Re: table.unpack(...) and the __index metamethod

[Tim Hill <drtimhill@...>]

On Jun 13, 2014, at 4:12 PM, Thiago L. <fakedme@gmail.com> wrote:

On 13/06/2014 20:10, Tim Hill wrote:

On Jun 13, 2014, at 7:25 AM, Andrew Starks <andrew.starks@trms.com> wrote:

> For performance reasons, all table accesses (get/set) performed by
> these functions are raw.

This makes sense to me. When I use unpack, it is very often in a spot where an expensive operation would be unwelcome.

However, I don't like these kinds of... "exceptions to the rules". Lua has metatables, I don't like to have to think about whether or not the standard library will respect them, or not. 

In the 5.1 era, when __ipairs wasn't around, the exception had a powerful reason: ipairs won't see your sequence and so neither will unpack. But now, it would be nice to see symmetry and "raw*" versions of the non-metatable variety, if the extra speed is needed... or some other, better method of achieving the same goal.

This is relevant to broader Lua because if I expect my module's table to be unpacked, then I need to export it as a "literal", as opposed to an object where the sequence is calculated.

-Andrew

The OP has a point though (imho) … table.unpack() is an iterated operation (internally), so the check for a metamethod could be done ONCE and so incur very little overhead for any non-trivial unpack operation, so you can get both performance *and* flexibility.

—Tim

We need a table.rawunpack(...)?

No, the OP pointed out that the overhead of doing the metamethod test in table.unpack() is low, since it can be done once at the start of unpack(), which then chooses a (fast) rawgeti() based loop or a (generic) index metamethod loop. So you get the best of both worlds in one API.

—Tim