Re: ipairs in Lua 5.3.0-alpha

[Jan Behrens <jbe-lua-l@...>]

On Fri, 15 Aug 2014 19:41:06 +0200
Dirk Laurie <dirk.laurie@gmail.com> wrote:

> 2014-08-15 18:37 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
> 
> > If the goal is only to reduce calls to length, another option would be
> > to modify ipairs so that it stops in the first nil entry with an index
> > larger than #t. That would have some nice properties:
> > ...
> > - It is more compatible with the original semantics of ipairs for
> > regular tables. (If no metamethods, it stops in the first nil, which
> > should be larger than #t in a proper sequence anyway.)
> 
> Even more compatible would be to revert to the version in 5.3.0-work3.
> "iterate over the pairs 1,t[1]), (2,t[2]), ..., up to the first integer key
> absent from the table."  I cannot understand why this simple and
> understandable specification was changed in 5.3.0-alpha.
> 
> However, I don't think __index should be respected by ipairs.
> It should just be the positive integer version of pairs, not something
> sophisticated and arcane.
> 
> If one wants #t (including __len) to be brought into the picture,
> the arithmetic `for` is available.

Wasn't ipairs() initially thought as syntactic sugar (without having to
bloat the language)? In Lua 5.1, there was practically no difference
between:

for i = 1, #t do local v = t[i]; ... end

 and

for i, v in ipairs(t) do ... end

Unless t was not a sequence (in which case #t is undefined),
or t was a userdata (in which case ipairs wouldn't work).


Regards
Jan