You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Objective C/C++ has "nil", so they rename it here to nil_. (the rest of the commit is unrelated test fixing). API breaking if you used nil, but seems prudent. Worth integrating?
The text was updated successfully, but these errors were encountered:
Actually I'm not sure if nil is needed altogether; is there a case where it behaves differently from an uninitialized (i.e. default constructed) object?
The docs indicate that it can be used to assign nil to a table element (or presumably any other luabind::object). It seems unused in the source code and tests aside from this.
A uninitialized object can also be used to assign nil, but only because it ultimately does lua_rawgeti(LUA_REGISTRYINDEX, LUA_NOREF) and there is nothing at LUA_NOREF (-2) in the registry. The Lua Reference Manual states:
The integer keys in the registry are used by the reference mechanism, implemented by the auxiliary library, and by some predefined values. Therefore, integer keys should not be used for other purposes.
So I think one could say that this behaviour is "implicitly documented" in Lua.
Saw this commit in the network:
wuhao5@7a3bdc5
Objective C/C++ has "nil", so they rename it here to nil_. (the rest of the commit is unrelated test fixing). API breaking if you used nil, but seems prudent. Worth integrating?
The text was updated successfully, but these errors were encountered: