Re: Bug report in length of simple table

[Miroslav Janíček <mira.janicek@...>]

> On 14 Sep 2016, at 16:04, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 
>> 3. As Josh Billings put it, "The trouble with people is not what
>> they don't know, but what they know and it ain't so." If your
>> sequence ain't a sequence, #t will give you a frontier, i.e.
>> a filled position where the next one is empty. So you can
>> just keep on doing "t[#t+1]=newvalue" and never overwrite
>> anything already in the array. This behaviour used to be
>> documented, was removed because it might confuse some
>> people, but now that it has become clear that people get
>> confused anyway, we hope that the next Lua release might
>> restore it, since the implementation has not changed.
> 
> We are planning to restore it. The new explanation would go like this.
> (What sounds better, "border" or "frontier"?)
> 
> --------------------------------------------------------------------------
> A *border* in a table 't' is any non-negative integer such that
> 
>   (border == 0 or t[border] ~= nil) and t[border + 1] == nil
> 
> That is, a border points to any position in a table where a non-nil value
> is followed by a nil value (or to 0, when position 1 is empty).
> 
> For instance, the table {1, 2, 3, 4, 5} has only one border, 5.  The
> table {1, 2, 3, nil, 5} has two borders, 3 and 5.  The table {nil, 2, 3,
> nil, 5, nil} has three borders, 0, 3 and 5. The table {} has one border,
> 0.
> 
> Note that any table has at least one border.
> Note also that keys that are not a non-negative integer
> do not interfere with the notion of borders.

Are these two notes correct?

It seems to me that a table with non-nil values for all positive integer keys {1 … math.maxinteger}, *and* a non-nil value for the key (math.maxinteger + 1) would not have a border.

  M.