Yes, I’ve now confirmed this via testing, so that is the definitive answer: IT IS NOT NECESSARY FOR A SCENE TO RETURN TRUE; IT MAY RETURN FALSE.
I stand corrected that returning true is necessary. I still think it’s advisable/good style, but it’s not strictly necessary.
As per standard Lua, [tt]return[/tt] at the end of a function is implicit, and the same as writing [tt]return nil[/tt].
Actually, this statement is not correct, and I think it was you who actually previously identified where in Luup this is troublesome, but to clarify:
It depends entirely on how the code receiving the return values is structured. A [tt]return[/tt] at the end of a function (implicit or otherwise) with no return values returns nothing, and that is different from returning nil. A more correct statement would be: all functions return a list of values, which may be empty. If the function has a return statement with no values, or contains no return statement (implicit return), then the return list is empty (zero length). Otherwise, the return list has length equal to the number of values in the return statement, and nil is a valid value. Thus [tt]return[/tt] on its own returns a list of zero length, but [tt]return nil[/tt] returns a list of length==1, where the one value is nil.
The fact that you get [tt]nil[/tt] when receiving return values into variables is an artifact of how the return list is assigned to the variables. All return variables are assigned ordinally–the first return value to the first receiving variable, the second return value to the second variable, etc. If a return variable’s ordinal position exceeds the length of the return list, it is explicitly assigned [tt]nil[/tt]; if the return list is longer than the receiving variables list, the excess return values are simply ignored.
[code]function test()
return “a”, “b”
end
local a,b,c,d = test()
print(a,b,c,d) – prints: A B nil nil[/code]
But in other contexts, the realities of Lua implementation are apparent. Take the case of a function wrapping another function, like: [tt]tostring( test2() )[/tt]:
[code]function test2()
return – nothing
end
– This fails!
print( tostring( test2() ) ) – runtime error: stdin:1: bad argument #1 to ‘tostring’ (value expected)
– But this works, because the receiver is assigned nil by list assignment
returnval = test2()
print(returnval) – prints: nil[/code]
So you can see that by receiving the function return into a variable (or variables), it APPEARS to return nil, but that’s not actually what is happening, and the fact that [tt]returnval[/tt] gets nil is an artifact/side-effect of the code structure, not how Lua actually returns values from a function.
And a further example showing this (adding code to the previous example):
[code]function howmany(…)
print(“I see”, #arg, " arguments!")
end
howmany( test2() ) – prints: I see 0 arguments![/code]
Again, I believe it was you that pointed out at least one example in Luup where an empty return list (nothing) is returned, rather than nil. I don’t recall what function that was, but I know [tt]luup.variable_get()[/tt] is such a culprit–if you request a variable for which the service or variable does not exist in user_data, the function returns nothing, and passing that directly to another function (like [tt]tostring()[/tt]) will get you into hot water. And of course, that same function is troublesome for functions like [tt]tonumber()[/tt] for a similar reason: it returns more than one value, but most people ignore that, and so many code examples people pass around receive only the first return value that I think most people aren’t even really aware that the function returns multiple values. But they quickly find out when they attempt to do the apparently sensible but actually incorrect [tt]tonumber( luup.variable_get( service, name, devnum ) )[/tt] (which doesn’t work as expected and should never be done).