| Agreed, and you suggest an interesting approach. Is the end-game of this an array that is (in effect), of a declared size? In this model, that is just what # returns all the time, and you can do all you like with nils and use whatever integer indexes you like (less than or greater than #), but not alter #. Of course, at that point # is just a fancy way of the old-style "n" field and thus has deteriorated to not being much use. Not sure I like this much.
The flip side here is subtle changes to the behavior of "nil", a more complex table API, and some boundary cases that might be a bit messy, but I agree that avoiding the introduction of a new type is worthy. The difference that matters to me considering your feature wish is,
that no additional value type that can be (ab-)used is required for
the proposal that I made, while still achieving a compatible solution
since you can then explicitly demand the existence of a nil value in a
table and have nils in arrays.
Because if a value does exists, it can also be nil, if it doesn't
exist, it's still nil but you can check that. You can of course not
pass "empty" to a function this way, which your idea allows, but that
can get easily around this if required through additional parameters
or functions in the API that you define yourself.
|
