[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: A more flexible table.remove
- From: Dirk Laurie <dirk.laurie@...>
- Date: Tue, 12 Jun 2018 12:12:43 +0200
2018-06-10 18:01 GMT+02:00 Soni "They/Them" L. <email@example.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.