Lua 5.1 has a serious issue

[Daniel Silverstone <dsilvers@...>]

Hi,

In my opinion (and the opinion of various denizens of lua-l and #lua)
there is a serious flaw in Lua 5.1's new # operator.

Specifically it is that it does not invoke the __len metamethod on
tables, only on userdata.

This results in an inability to do interesting things with the #
operator on objects implemented in pure lua. Consider a special
sparse-array as a critical example -- the default implementation of # on
a table (luaH_getn) clearly will never work reliably on a sparse array.
But if the __len metamethod were checked for on tables also, then it
would clearly allow for the implementor to sort it out.

I know this has external effects on the language and that this late in
the game this is frowned upon, but honestly I thought it was a mistake
in the beta and would have been corrected before the release candidate.

It's fairly easy to replace the chunk in lvm.c for handling OP_LEN for
tables to be something like:

          case LUA_TTABLE: {
            const TValue *tm = luaT_gettmbyobj(L, rb, TM_LEN);
            if (ttisnil(tm)) {
              setnvalue(ra, cast(lua_Number, luaH_getn(hvalue(rb))));
            } else {
              Protect(callTMres(L, ra, tm, rb, &luaO_nilobject));
            }
            break;
          }

And such would save a lot of hassle and prevent us from having another
second-class metamethod to go alongside __gc.

I appreciate that the docs may need tweaking as a result of this, but I
seriously recommend it be done. Otherwise I can see many distributions
applying such a patch as a "bugfix" which will make varying and
effectively incompatible versions of Lua occupy our distributions.

D.

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895