> 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
