> The only reason it exists is due to the way the C API retreives arguments from the stack. Without select, which is a C function, there would not even be a way to check this in lua. Eliminating it would arguably be more minimalistic? There's always been a discontinuity with arguments, a lua function which binds 1 argument to a parameter can be called with f() and f(nil) indistinguishably (without using C functions to check) which is not the case for C function calls.
This reminds of a similar discussion a couple of years ago where I said:
> I should say that the TNONE vs TNIL difference is very arcane and confusing. And this difference only exists for C functions, and one can make a C function conform with the documented behaviour (3.4.11), or not.
and
> Another problem is that your language above implies that we somehow must expect that setmetatable should behave like a "C function" and not a like a Lua function. Why? I do not think "because it is implemented in C is a sensible answer for someone who has no idea about the implementation of Lua. And why, indeed, should we expect that C functions behave differently? The difference is explained very compactly at the end of section 4.3, but it only makes sense for a C programmer, not for a Lua programmer (a pure Lua programmer would not even look there), who still sees there "virtual type LUA_TNONE, which behaves like a nil value". Does that imply that every user of Lua should understand the arcane details of Lua's C language API? I think that would be too much to expect.
It was a lengthy thread, too.
Cheers,
V.
