Re: ipairs in Lua 5.3.0-alpha

[Dirk Laurie <dirk.laurie@...>]

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.

My conceptual objection is that the base library should not be
targeted to the special needs of people who need metamethods
to the point of inconveniencing those who do not. That stuff
can go into the table library, which has a long history of being
misunderstood if not disliked by many and seems destined
to continue in that great tradition.