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

[Andrew Starks <andrew.starks@...>]

On Sat, Jun 14, 2014 at 3:42 PM, Tim Hill <drtimhill@gmail.com> wrote:

On Jun 14, 2014, at 3:25 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

> 2014-06-14 8:27 GMT+02:00 Tim Hill <drtimhill@gmail.com>:
>>
>> Anyway, I’m not tied to this but I still think the OP had
>> a good point. The Lua ref notes in a couple of places
>> the raw accesses are done for speed, but he is correct
>> in noting that you don’t need to sacrifice non-raw access
>> for speed in this case.
>>
>
> The manual (which anyway refers you to other places for
> the decisions behind the design of Lua) only says "For
> performance reasons", true, but that is not the only reason.
>
> You can't have one rule for concat and unpack and another
> rule for insert, remove and sort. But for the mutable table
> functions, semantics becomes a mare's nest unless you
> have raw access.
>

Well you CAN have different rules, whether you want to or not is a different matter. Since table.unpack() doesn’t mutate the table I don’t see any real problem.

As for mutable table functions, I’m not sure I see the mare’s nest you do, but that’s not the issue here.

As I said, the stated reason for not having metamethod access during unpack doesn’t seem to be necessary. I can’t comment on “unstated” reasons, since they are unstated :)

—Tim

I guess I am curious about the mare's nest...

Once there was a time without __ipairs. Now, it we have it.

Why is there a mare's nest with unpack, but presumably there isn't one happening with __ipairs?

-Andrew