Re: Bug report in length of simple table

[Philipp Janda <siffiejoe@...>]

Am 14.09.2016 um 16:23 schröbte Peter Aronoff:
> Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > <advanced>
> > This turn is caused is caused by the different ways in which the tables
> > are stored (all in the "array" part in the first case, only one element
> > in the "array" part in the second case). The details are quite involved
> > but basically #t will not change as long as you assign to indices that
> > exist (even if they have value nil)
> >
> > $ lua
> > Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> > > t={1,nil,nil,nil,nil,nil,nil,nil,nil,10}   -- indices 1 to 10 exist in the "array part"
> > > #t   -- there is a non-nil at the highest "array part" index
> > 10
> > > t[5]=5  -- assigning to an existing index does not change #t
> > > #t
> > 10
> > > t[12]=12  -- non-existing index triggers resizing of "array part"
> > > #t     -- [5], [10] and [12] are now in "hash part"
> > 1
> > </advanced>
>
> While we are on this *advanced* subject, I have a question: none of this
> “array part” and “hash part” stuff is guaranteed, right? That is, you
> shouldn’t rely on it in your code, should you?

No, you shouldn't, because one's assumptions about hash/array parts are 
often wrong. E.g., on my machine Lua stores `{[1]="a",[2]=nil,[3]="c"}` 
in hash slots only.
I wish people would stop talking about hash and array parts. They are of 
no consequence except for performance and memory consumption.

Philipp