Re: Surprising behavior of table.insert()

[HyperHacker <hyperhacker@...>]

On Fri, Feb 25, 2011 at 14:17, Patrick Donnelly <batrick@batbytes.com> wrote:
> On Fri, Feb 25, 2011 at 4:11 PM, Axel Kittenberger <axkibe@gmail.com> wrote:
>> Eitherway you should never "insert nil" into a list, if i recall
>> correctly, the behavior is undefined depending on the array/hash state
>> of table.
>
> There is nothing undefined about it. The manual is quite clear:
>
> "Inserts element value at position pos in table, shifting up other
> elements to open space, if necessary. The default value for pos is
> n+1, where n is the length of the table (see §2.5.5), so that a call
> table.insert(t,x) inserts x at the end of table t."
>
> There is no shifting in this case, obviously, because the given
> example always appends. I think relying on *appending* nil to a table
> being a no-op is entirely reasonable.
>
> The real problem is the not passing an "x" value to insert. It should
> be harmless enough to assume x is nil. After all, table.insert does
> not blow up when given an explicit nil.
>
> P.S. Please do not top-post.
>
> --
> - Patrick Donnelly
>
>

This is a bit of a design problem in my opinion, and it's present in a
number of C libraries as well, which use lua_isnil where they should
use lua_isnoneornil (or perhaps luaL_opt* make this mistake for
them?), thus leading to situations where I have to call foo(nil, nil)
instead of just foo(). I recall this being a problem with LuaGTK,
though I believe it's been fixed already.

It's interesting to note that lua_isnumber returns true for strings
that can be converted to numbers, so perhaps lua_isnil should return
true for "no value", thus fulfilling the expectation that missing
arguments and nil arguments are the same? You'd still be able to do
(lua_isnil(L, n) && !lua_isnone(L, n)) if you wanted to differentiate
the two for some reason.

-- 
Sent from my toaster.