Re: 'table' as fallback for tables

[Philipp Janda <siffiejoe@...>]

Am 26.06.2016 um 20:23 schröbte Tim Hill:
> [...]
>
> (As I noted in my earlier post)

Yes, some of those. I've repeated them for completeness.

> > Downsides:
> > *  Modifying an array range would be a two step process; you couldn't shrink an array just by assigning `nil` to `t[#t]`, or grow it by assigning to `t[#t+1]`. I suppose most people would start using the table library functions for this (if they don't do that already).
> > *  Counting elements in table literals is cumbersome (Lua could help with that, though).
>
> But that was my whole point. An *explicit* array size, which means it’s set explicitly by the user. The default for a table is 0.

I wouldn't use a default size. We'd lose the ability to check for 
non-array tables.

> If you set size to (say) 5, then you have 5 elements, (1..5). Doesn’t
> matter if some are nil, doesn’t matter if you have keys 6, 7 and 8 ..
> the size is still 5. This is, as I said, similar to “.n” but it’s
> *first class* ..

So far it's exactly like ".n", and I didn't know what you meant by 
"first class".

> so #t returns 5, and obeys __len metamthods (so there is no ugly “.n”, just the built-in # operator and a yet-to-be-determined way to set the size).

I think the `#t = 3` syntax is still available, but where would you 
_store_ the size? Somewhere in the C struct making *all* tables bigger? 
Also, what should happen if you try to copy a table via `pairs()`? So 
far I like `.n` better.

>  [...]
>
> As I said, the scheme is far from perfect, but it’s more consistent that the current incoherent approach of .n, # and sequences imho.

I agree. Most of it could be realized via a library without support from 
the Lua core ...

> —Tim

Philipp