Re: tables holding nil
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: tables holding nil
- From: Cosmin Apreutesei <cosmin.apreutesei@...>
- Date: 2009年7月23日 15:59:29 +0300
On Thu, Jul 23, 2009 at 02:25, Cosmin
Apreutesei<cosmin.apreutesei@gazolin.ro> wrote:
>> If nil is allowed as a table key, then next() would have to use some
>> other value for the beginning and end of a table.
>
> Actually, I never liked the fact that nil is used to signal the end of
> an iteration. Whenever I build an iterator that might return nil
> elements, I have to put a pseudo-index as the first return value of
> the iterator as a workaround.
To allow iterators to return nil as a value, the iterator protocol
could be generalized as
do
local f, s, var_1, ···, var_n = explist
while true do
local more, var_1, ···, var_n = f(s, var_1, ···, var_n)
if not more then break end
block
end
end
Should next() continue to be the iterator returned by pairs() (but who
says it shoud), its common usage scenario would be
more,k,v=next(t)
while more do
........
more,k,v=next(t)
end
This would allow constructing simple iterators for sparse arrays,
sets, or varargs, all of which can return nil as a valid value.