Re: [ANN] Lua 5.3.0 (alpha) now available

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

A few comments about the changes in ipairs in Lua 5.3.0 (alpha):

(it seems that those were already in Lua 5.3 work 3, but I didn't notice them previously, and I didn't find many discussions on this in the lua-list or on google...)

1) I find that the deprecation of the __ipairs metamethod is a really welcome simplification. 
Actually the __ipairs functions I had to write  for various userdata types were all an almost exact duplicate of what is now function ipairaux in lbaselib.c.

2) IMO the new behavior of ipairs is simple and consistent (even if different of the 5.2 behavior in a few corner cases). 
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? :-)

3) I was wondering if the same kind of changes couldn't benefit to the 'pairs' function, i.e. to deprecate the '__pairs' metamethod and to replace it by a more generic iterator metamethod , let's name it here  '__next'...
This would be used by 'pairs', but also by 'lua_next' and 'next', giving a way to iterate in any table or indexable userdata with the same set of APIs both from Lua or C code.

From a design standpoint, '__next' would need an iterator context information in its parameters, so it could be defined as something like:
key, value, context = __next(var, context), called as __next(var, nil) when staring the iteration.

Note: I already use this type of metamethod in a debugger variable inspector, to have a consistent display of Lua table and userdata, and it works fine.

Jean-Luc