Re: upcoming changes in Lua 5.2 [was Re: Location of a package]

["Peter Cawley" <lua@...>]

* If you want things like "for key, value in t do ..." then simply
attach a __call metamethod to the table.
* I would prefer to see __next over __pairs, as "for key, value in
next, t do" and "for key, value in pairs(t) do" are currently the
same, and it would be nice to keep that. Also could mean that lua_next
from C would respect the __next metamethod allowing C code to iterate
custom tables (although this would have to come with lua_rawnext)
* I would also prefer ipairs to use __index over an __ipairs
metamethod, as there is usually only one way you want a table
iterated, so just set __pairs to whatever iterator you want rather
than setting __ipairs or __pairs.
* Allowing an explist for the numeric for is also something I would support

On 21/02/2008, Jean-Claude Wippler <jcw@equi4.com> wrote:
> > (The semantics is that __ipairs, if present, is called and its
>  > result is the final result of ipairs. So __ipairs is not called on
>  > each iteraction; it is called before the loop to return an iteraction
>  > function.)
>
>
> Supposedly this means the pairs/ipairs calls are still used?
>         for i in pairs(blah) do ...
>         for i in ipairs(blah) do ...
>
>  Or might the goal be to get rid of them, once __pairs and __ipairs are
>  added?
>         for i in blah do ...
>  (seems more intuitive to me, i.e. blah responds to an iteration
>  protocol, being "__pairs")
>
>  Not sure about implicit ipairs though - perhaps with a new notation?
>         for i in *blah do ...
>  Hmm, I don't quite grasp the role of ipairs, when there is also
>         for i=1,#blah do ...
>
>  (and I still think "for i=f() do ..." could be a useful way to supply
>  non-standard bounds)
>
>
>  -jcw
>
>
>