Re: Subject: Re: [ANN] Lua 5.2.2 (rc2) now available

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

>> Can I suggest it would be safer to return nothing for pos==#t+1,
>> and error for pos>#t+1?
>>
>> My concern is that # (or more accurately luaL_len) uses any '__len'
>> metamethod, so we really should not be depending on the assumption that
>> t[#t+1]==nil (or that t[#t+2]==nil for that matter).
>
> This seems a little nit-picking, does it not?

Let's apply the Three Questions as posed in

   http://www.inf.puc-rio.br/~roberto/talks/ws2011.pdf

Q1.  How frequently does it happen?.
A1.  When
    (a) there is a __len metamethod;
    (b) there is be a non-nil at pos #t+1.

Q2. How easily can we detect it?
A2. One more test in the C code, equivalent to "if pos==#t+1".

Q3. How easily can we correct it?
A3. In the C code, `return 0`; in the reference manual, the addition of
   "except when pos=#t+1, in which case nothing is removed and nothing is
   returned."

In the case A1(b), if it is a user error, an error message is the correct
response; if the user has taken into account that `remove(t,pos)` might
be called with `pos==#t+1`, the correct response is debatable, and in fact
is being debated right now. Personally I don't care much either way: that
judicious user is perfectly capable of reading the Reference Manual.

Provided, of course, that the Reference Manual says what happens. Perhaps
change the last sentence of the documentation of 'remove' from

    The default value for `pos` is `#list`, so that a call `table.remove(t)`
    removes the last element of list `t`.

to

    The default value for `pos` is `#list`, so that a call `table.remove(t)`
    removes the last element of list `t`; the largest legal value for `pos`
    is `#list+1`.