Re: table.unpack(...) and the _

Ahh. Your/Dirk's point is that next behaves the same as unpack behaves the same as rawgeti, etc. Presumably, "where would the madness end...?"

`next` *is* different. It is the only "function" that does something that is magic. There is no way to write it, without `next`.

I hate to use that specialness as a reason why I don't think it should read metatables, but I will. If you're special, you should also be limited.

There are many other examples where the standard libraries don't respect metatables. I have varying degrees of dislike for all of them, except next.

-Andrew

On Sat, Jun 14, 2014 at 6:03 PM, Thiago L. <fakedme@gmail.com> wrote:

On 14/06/2014 19:59, Andrew Starks wrote:

On Sat, Jun 14, 2014 at 5:24 PM, Thiago L. <fakedme@gmail.com> wrote:

On 14/06/2014 18:18, Andrew Starks wrote:

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

for x,y in next,setmetatable({},{__index={1,2,3}}) do print(x,y) end

That does not really answer my question, does it?

That of course, will print nothing, because __ipairs is not defined. The question I had was:

How is there *not* a mare's nest with the existence of __ipairs, but there would be one if table.unpack respected metatables? (presumably __ipairs, or perhaps __index?)

for x,y in next,setmetatable({},{__index={1,2,3},__pairs=function(t) return error,t end,__ipairs=function(t) return error,t end}) do print(x,y) end

My point is that next is basically rawget without rawget