Re: Bug in 5.3 ipairs(), or feature?

[Coda Highland <chighland@...>]

On Wed, Mar 4, 2015 at 8:13 AM, Michael Welsh Duggan <mwd@cert.org> wrote:
> In Lua 5.2, ipairs() on any non-table (or table-like) type would throw
> an error.  In 5.3, ipairs("foo") or ipairs(nil) returns a valid iterator
> function, as long as LUA_COMPAT_IPAIRS isn't turned on.  (It is turned
> on by LUA_COMPAT_5_2, which is the default in the base release.)
>
> For nil, I get something useful on iteration:
>
>   > for i, v in ipairs(nil) do print(i, v) end
>   stdin:1: bad argument #1 to 'for iterator' (table expected, got nil)
>   stack traceback:
>           [C]: in function 'for iterator'
>           stdin:1: in main chunk
>           [C]: in ?
>
> But for a string I get, unexpectedly, nothing.
>
>   > for i, v in ipairs("foo") do print (i, v) end
>   >
>
> So...  Bug, or feature?  I vote bug, if for no other reason than the
> inconsistent behavior.

It's only inconsistent if you're comparing it to 5.2. It presents no
inconsistency with the rest of the language -- it defines ipairs as
"iterate over the sequence contained within this object" and has
"don't iterate at all" as the degenerate case instead of "generate an
error in some cases or don't iterate at all in others".

/s/ Adam