Re: Why do we have ipairs?

[Coda Highland <chighland@...>]

On Mon, Jun 9, 2014 at 9:14 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
> On Mon, Jun 9, 2014 at 9:25 PM, Thiago L. <fakedme@gmail.com> wrote:
>>
>> Last I checked, `for x,y in ipairs(t) do` is slower than `for x=1,#t do
>> local y = t[x]`, so why do we have ipairs()?
>>
>
>
> In 5.2, __len and __ipairs made that a easy answer: you can override them
> independently. In 5.1, someone else might have a better answer than i.

# isn't a constant-time operation -- it's O(log n) in the size of the
table. Furthermore its behavior is only well-defined for a proper
sequence, wherein the table contains no nil-valued entries with
integer keys less than the greatest integer key with a non-nil value.
ipairs(), meanwhile, stops at the first nil value encountered in the
table. Semantically, ipairs() is the more well-defined behavior.

Ultimately, it's the semantic behavior that gives ipairs() its value
-- not because it's faster, but because its use parallels the behavior
of pairs() and any other iterator function defined.

/s/ Adam