Re: [ANN] Lua 5.3.0 (alpha) now available

[Andrew Starks <andrew.starks@...>]

On Thursday, July 31, 2014, Tim Hill <drtimhill@gmail.com> wrote:
> On Jul 31, 2014, at 12:42 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
> >
> > All of the information efficiently presented and present...
> >
> > Original:
> > `Copies elements from table a1 to table a2. This function performs the equivalent to the following multiple assignment: a2[t],··· = a1[f],···,a1[e]. The default for a2 is a1. The destination range can overlap with the source range. Index f must be positive.`
>
> More inscrutable to me is why f must be positive.
>
> > I also agree that "table.copy" seems to suggest "any key value". Obviously its definition clears that up. "table.icopy" seems to fit "pairs" and "ipairs", but I don't mean to nitpick.
>
> +1 for table.icopy(). However, I would guess that in actuality this is just a fast, numeric index copy not restricted to arrays/sequences (which table.icopy() name might suggest). That is, it works even with holes (nil values) in the copied range, which is implied by stating that it is equivalent to a multiple assignment statement.

I see. This also explains the choice in how it was illustrated. If defaults were (1. #a1, 1), then it could support both arrays and numeric keys. Then I opt works and it retains its vararg compatibilities. Correct?

I that I'm going beyond "all comments are welcome" when I suggest adding features to it, of course.

 

> > It was mentioned that "table.clear" (or similar) was likely. Was it decided that it would not be useful?
>
> My guess here is that there is no real performance gain. There are a number of tricks table.copy() can do to optimize the copy that can’t really be coded in Lua (not saying it DOES these, just that it COULD), while a clear function in Lua is pretty much as good as a C version.
>
> —Tim

I thought it was said that internally, Lua could lop off a single reference, clearing the table in "one" go. That may have been speculation.  

-Andrew