 |
lua-l archive |
|
|
||
|
On 2018-06-12 07:12 AM, Dirk Laurie wrote:
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.
remind me of young me trying to use table.insert and (more importantly) table.remove to set and unset arbitrary keys, not just integers.
because that's a thing that happened.because it would've been nice, to be able to treat integer and non-integer indices the same, and have the good hole-free semantics of table.remove.
because sometimes you want your API to treat tables as arrays + maps, not exclusively arrays (with table.remove) or exclusively maps (with t[x]=nil). but you don't want to write workarounds yourself (`if not pcall(table.remove, t, x) then t[x] = nil end`, I guess???).
and I happened to notice, a few days ago, that this change would also help with the move towards nil-in-tables.
(I'd argue we can have all this and still keep errors on out-of-range, tho... at least for table.insert.)