 |
lua-l archive |
|
|
||
|
Am 04.07.2013 03:45 schröbte Andrew Starks:
My suggestion is that when asked for the value's type, a default behavior
for a table can still be to return nil, even if there is no key set for the
given index. It doesn't store a value for that index, yet when asked it
still says nil.
As was previously suggested, a simple way to find out would be to extend
type such that:
type({empty(), empty(),3})[2])
--> nil, undefined
That is basically the explicit/implicit (defined/undefined) nil approach, not the table-index-is-vararg approach. The former requires less changes to Lua as is, but introduces a new value which inherits the problems of the current nil value, and it makes __index messy. The later is basically an alternative to raising an error when accessing an undefined value in a table, and it doesn't need a new value. Both approaches need an incompatible way of deleting values. In fact *any* approach which allows storing nils needs a new syntax for removing values (or new syntax for storing nil, `t[n] = nil` cannot be used for both).
Another syntactic trick may be too have lua do this:
local foo
select("#", foo) --> 1
select("#", (foo)) --> 1
select("#", baz) --> 1 -- today's behavior, intact thus far
select("#", (baz)) --> 0 -- new behavior.
This is a bad idea in both approaches:It reuses existing syntax for a completely different (and incompatible) effect -- it actually *reverses* the usual behaviour in the table-index-is-vararg method. And it doesn't really apply to the explicit/implicit nil method, because there are no variable value lists involved (baz always has exactly one value) ...
Philipp