[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: A more flexible table.remove
- From: "Soni \"They/Them\" L." <fakedme@...>
- Date: Tue, 12 Jun 2018 08:15:55 -0300
On 2018-06-12 07:12 AM, Dirk Laurie wrote:
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.
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
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.)