Assorted proposals dealing with assorted issues. Some of this comes
down to
deciding what the key problem is that needs solving and how much
syntactic
help is needed or at least how little hostility is needed.
Proposal 1
----------
* Magic element named '#' gives the length of the table. If not
provided, it
gets calculated. For #t, this results in one more lookup for what was
already a search.
* This works just like the old 'n' field except that there is
probably no
magic shadow table. It's basically just a name change. (If someone
wants to
argue for the shadow table, I'm not ruling it out but I think we
just live
with tables with length being longer.)
* Table construction that includes the token # will include a '#'
field:
t = { #, 1, nil, "baz" }
print( #t ) -- 3
print( t[ '#' ] ) -- 3
t = { #, ... } -- varargs capture
Note that one should get the same value for # no matter where it gets
included in the constructor. This is important because { ..., # }
would only
capture the first element of the varargs (if it's even legal).
Proposal 2
----------
Leave tables as they are, but introduce more efficient mechanisms than
select for dealing with varargs. Specifically, allow:
#... to get the length of the varargs
And
...[ i ] to index the varargs
This then allows one to write things like:
for idx = 1, #... Do
local v = ...[ idx ]
-- processing
end
Proposal 3
----------
Tuples to capture sequences containing nil. This can be done with
functions
but they are crude because they don't support #tuple and tuple
[ idx ]. This
can be done with userdata but it gets a bit expensive and leaves
open the
question of why one needs to bail out to userdata to work around
language
"issues".
Mark
