Re: ipairs in Lua 5.3.0-alpha

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

On Fri, 15 Aug 2014 10:50:04 -0700
Coda Highland <chighland@gmail.com> wrote:

> On Fri, Aug 15, 2014 at 10:47 AM, Doug Currie <doug.currie@gmail.com> wrote:
> > On Fri, Aug 15, 2014 at 1:16 PM, Jan Behrens
> > <jbe-lua-l@public-software-group.org> wrote:
> >>
> >> On Fri, 15 Aug 2014 13:37:41 -0300
> >> Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> >> [...]
> >> > 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 sounds like a "hack" to me.
> >
> >
> > It is very clever. I like it.
> >
> 
> I like it too!
> 
> >>
> >> If we assume that nil's are allowed as values, then calling the length
> >> operator here (even if it's just for a few nil elements) would require
> >> the underlaying SQL library to iterate through all result rows to
> >> return a length.
> >
> >
> > No, you simply need to return the current index + 1 to continue the loop.

I don't understand what you mean with "simply returning the current index + 1"?

> 
> Not to mention a lot of drivers know the size of the resultset before
> they start streaming records to you anyway.
> 
> /s/ Adam
> 

And some drivers don't. It would be nice to be able to use ipairs(...)
here as well. What's the sense of ipairs anyway, if it behaves the same
as the arithmetic "for"?

-- Jan