Evaluate box.NULL to false

[knazarov]

Currently the following code prints surprise:

local a = box.NULL

if a then
         print('surprise')
end

It is not obvious for many new and existing users of tarantool, and is a constant source of bugs, because nil gets converted to box.NULL by net.box, memtx and others. So users should be constantly mindful to write "if a ~= nil" instead.

[MariaHajdic]

We cannot simply replace msgpack.NULL (and its alias box.NULL) with nil because Lua doesn’t distinguish nil from absence of value in a table. But even though msgpack.NULL equals to nil it still has type cdata and thus the statement "if msgpack.NULL" would be always evaluated to true as well as "msgpack.NULL == nil" and there seem to be no way around it. Unless of course we consider implementing macros (or use someone else's implementation of macros for lua, e.g. - https://github.com/stevedonovan/LuaMacro). This would allow to keep the existing functionality and being able to use box.NULL in most intuitive straightforward way at the same time.

[Totktonada]

Related: tarantool/doc#561

[igormunkin]

@knazarov, OK, let's start with Lua and LuaJIT manuals:

• Lua reference manual

The condition expression of a control structure can return any value. Both false and nil are considered false. All values different from nil and false are considered true (in particular, the number 0 and the empty string are also true).

• LuaJIT FFI semantics

Pointer comparison: two compatible cdata pointers/arrays can be compared. The result is the same as an unsigned comparison of their addresses. nil is treated like a NULL pointer, which is compatible with any other pointer type.

Considering all sources above this behaviour is documented in both Lua language spec and FFI semantics description.

Moreover, let's take into account the Java spec:

The Expression must have type boolean or Boolean, or a compile-time error occurs.

Thereby Java Compiler obligues the one to use an explicit comparisons within a conditional expression and I see no problem with it. We can start flaming about value evaluation/conversion to boolean in other languages but it is more a hack than a best practice.

Assume we make this change. What is the reason to stop with ffi.new('void *', 0) and left both 0 and '' still evaluating to true? Strictly saying, there is no difference between them for me except the caveat in FFI semantics mentioned above.

We can continue the discussion, but for now I see lots of work with no sense for such breakage and propose to close this issue with no changes to be provided.

[olegrok]

Related issue - #1666