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

[Rena <hyperhacker@...>]

On Jul 12, 2016 12:29 AM, "Dirk Laurie" <dirk.laurie@gmail.com> wrote:
>
> 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.
>

Unless t is empty.