Re: New array type? (was: 'table' as fallback for tables)

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

2016-07-11 21:43 GMT+02:00 Roberto Ierusalimschy <roberto@inf.puc-rio.br>:
>> On 7 July 2016 at 19:20, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> > At least the implementation still guarantees that; it is only a
>> > documentation matter...
>>
>>
>> BTW, why was that guarantee removed?
>
> There was a thought that explaining the guarantee made the '#' still
> more difficult to be understood. It would be easier to simply say "it
> does not work with holes" than trying to explain that it did work with
> holes, but not exactly in the way you might expect. Currently, I think
> that those that do not understand '#' (and most others) do not bother to
> read the manual, so what we say would make no difference to them, but
> the guarantee could be useful for those that read the manual.

Since we already have an explanation of the concept "frontier" for
a string in §6.4.1, it would be conceptually easiest to make the
present algorithm available under the name table.frontier. Then the
explanation of #t would merely be "If t has no __len metamethod,
#t is the result of the function also supplied as table.frontier(t)."

The documentation of table.frontier is the right place to explain the
subtleties of the procedure. Not only is the language description
kept uncluttered but the table library is the one place where people
really need to reminded about it.

Ir is of course not quite correct to say that t[#t] is not nil but t[#t+1]
is. The truth is that rawget(t,#t) is not nil but rawget(t,#t+1) is.