[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.2.0 (beta-rc1) now available
- From: Dirk Laurie <dpl@...>
- Date: Tue, 14 Jun 2011 11:55:35 +0200
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