lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Jun 14, 2011 at 06:18:58AM +0200, Lorenzo Donati wrote:
> On 14/06/2011 6.06, Xavier Wang wrote:
> > it means: this table:
> >
> > local t = {1, 2, nil, 4}
> >
> > in lua5.1.4, #t will be 2 or 4, but in lua5.2, #t is undefined.
> >
> >
> >
> Ouch. I assumed that to mean that the _concept_ of "length" is 
> undefined, not what # returns. But maybe I assumed too much.
> 
If you gvimdiff the actual code of ltable.c and ltablib.c from
lua-5.2-alpha to lua-5.2-beta, you will see that what # returns,
and in fact the behaviour of the whole table library, stays the 
same if all numeric keys are integers.  But the reference manual 
no longer specifies a definition of # for the non-list case.

So, the net result of those that bashed the newbie-unfriendliness
of the definition of # is that it is now out of the Lua specs and 
in principle out of future implementations too, though not yet out 
of this one. I hope they are happy with their achievement.

> I think some people won't be happy if what you say is true. IIRC some 
> people found a useful use for the behaviour of # when a table has holes 
> in 5.1.4 (filling unfilled slots or the like, I don't remember well).
> 
> If you interpretation is right (as it could be), if a table t has holes, 
> i.e. it is not a sequence in the new jargon, #t may well return nil or 
> whatever it likes.
> 
> If this is true, I think it should be pointed out among the 
> incompatibilities at the end of the manual.
> 
I agree.  Sadly.

Dirk