lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Fri, Feb 25, 2011 at 14:17, Patrick Donnelly <> wrote:
> On Fri, Feb 25, 2011 at 4:11 PM, Axel Kittenberger <> 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.