Re: Changes to table length

["Soni L." <fakedme@...>]

On 20/08/16 09:17 PM, Martin wrote:
> On 16-08-20 07:04 AM, Soni L. wrote:
> > > local len = 1
> > > while (t[len] ~= nil) do
> > >     len = len + 1
> > > end
> > > return len
> > You should probably return len - 1. Otherwise {} has len 1 and {1} has
> > len 2.
> You're right.
>
> > Tables shall be k/v pairs. The concept of an "array" shall be userland.
> They already are.
>
> So if I understand right you offer just drop part of existing
> functionality for the sake of conceptual clearness. I think this
> decision is hard to accept for many users.

It is. But I can't come up with a better option.

This is the only reasonable way I can come up with to reinforce the 
notion that tables are k/v pairs and nothing more. I mean, I can come up 
with unreasonable ones too, from least intrusive to most intrusive:

- Put "LENGTH IS UNDEFINED" wherever the manual mentions table length.
- Remove list syntax. (you know, {1, 2, 3, 4, 5})
- Print "LENGTH IS UNDEFINED" to stderr every time the length operator 
is used.
- Put the length operator behind a "feature gate" that needs to be 
applied per chunk, otherwise the compiler tells you that "length is 
undefined and tables are only k/v pairs" and stuff and refuses to 
compile your code.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.