ipairs in Lua 5.3.0 (alpha)

[Jean-Luc Jumpertz <jean-luc@...>]

Moving this to a new thread to avoid polluting the Lua 5.3.0 (alpha) announcement.

Le 1 août 2014 à 14:41, Philipp Janda <siffiejoe@gmx.net> a écrit :

>>>> And btw testing the  '__len' and '__index'  metamethods in function 'luaB_ipairs' has an almost null performance cost and gives you additional flexibility, so what would it bring to restrict this test to the '__len' metamethod, as Philipp Janda proposed? :-)
>>> 
>>> It's useless code that causes one extra case of undefined behavior, so why keep it? And what's the additional flexibility?
>> 
>> The additional flexibility is to allow you to freely define the values you want to return for table[i] and to keep it consistent between direct accesses like << a = my_table[i] >> and for loops like << for i, v in ipairs(my_table) >>, even if you don't redefine __len
> 
> As I argue above, you can't. `__index` without `__len` is either superfluous ( `__index` never gets called) or highly unpredictable (undefined behavior, could stop in mid-loop in current Lua implementation).

Can you elaborate on this? I really can not get your point here...

It looks to me that  `__index` without `__len` would be appropriate in the case of an indirection-typed data structure, where the value returned by __index is based on the raw value stored in the table and preserves the nil table entries. Which is not an uncommon pattern.