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

[Tim Hill <drtimhill@...>]

On Aug 1, 2014, at 2:49 AM, Jean-Luc Jumpertz <jean-luc@celedev.eu> wrote:


> 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.
> 

To my mind all this really comes down to how far Lua wants to go down the “generic” path. This was discussed some time ago in the context of table.sort() where it was noted that, if it respects metamethods, then table.sort() has nothing really to do with tables; it’s a generic sort() function that can sort anything that exposes the appropriate metamethods (that is, is “sortable” in the interface sense). It seems that 5.3 is putting it’s toes into generic coding with ipairs(), which again decouples iteration from its roots as a table-only function.

I’m a bit surprised, however, that __ipairs() was deprecated. I see no reason why you can’t have both __ipairs() and respect metamethods; ipairs() simply defers to __ipairs() for the whole iteration if found, while otherwise using it’s default behavior and respecting __index() etc.

—Tim