Re: A more flexible table.remove

[Dirk Laurie <dirk.laurie@...>]

2018-06-10 18:01 GMT+02:00 Soni "They/Them" L. <fakedme@gmail.com>:
> table.remove has some unnecessary restrictions:
>
>> Removes from list the element at position pos, returning the value of the
>> removed element. When pos is an integer between 1 and #list, it shifts down
>> the elements list[pos+1], list[pos+2], ···, list[#list] and erases element
>> list[#list]; The index pos can also be 0 when #list is 0, or #list + 1; in
>> those cases, the function erases the element list[pos].
>>
>> The default value for pos is #list, so that a call table.remove(l) removes
>> the last element of list l.
>
> This should be changed such that:
>
> - pos can be a non-integer. in which case, the value is simply removed.
> - pos can be negative.
> - basically pos should be called index and it should just shift things
> up-one or down-one when it makes sense to do so.
>
> This allows new code to use table.remove instead of t[x] = nil. This would
> start a transition period between tables-with-holes and nil-in-tables.

Personally I like the fact that table.insert and table.remove give
errors on out-of range indices, because it has helped me in debugging.

I'm not altogether sure that this post is really serious. I prefer to
read it as just another indication of the ridiculous consequences that
the nil-in-table notion would have got us in.