2014-08-19 11:34 GMT+02:00 David Demelier <demelier.david@gmail.com>:
Le 02/08/2014 09:16, Dirk Laurie a écrit :
This subject is too important to be buried in the big thread.
The idiom
for k,v in ipairs(tbl) do
appears in numerous programs, very few of which are paranoid
enough to test (redundantly, up to now) that v is not nil. f you
explicitly supply __ipairs, you take responsibility, fair enough.
Now __ipairs is deprecated (although still recognized with default
compatibility options) and that idiom is equivalent to
Mmm, how can you use ipairs on a userdata if the metamethod __ipairs is
removed ? Do you need to implement an __index function which verify if the
index value is an integer?
The motivation seems to be that if __len and __index is provided,
then the only consistent meaning of ipairs is that
for k,v in ipairs(tbl) do
does the same as
for k=1,#ipairs(tbl) do local v=tbl[k];
that there is therefore no need for a separate __ipairs metamethod;
and that the need to provide that every time is an avoidable nuisance.
My main practical problem with that is that I actually have code
which relies on the present behaviour of ipairs: iterate rawget as
long as the value is not nil, and I doubt whether I am the only one
who has.
