[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (alpha) now available
- From: Coda Highland <chighland@...>
- Date: Thu, 31 Jul 2014 13:56:24 -0700
On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <firstname.lastname@example.org> wrote:
> On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <email@example.com> wrote:
>> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <firstname.lastname@example.org>
>> > ---
>> > table.copy (a1, f, e, [a2,] t)
>> > 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.
>> > ---
>> > I have mixed feelings about this. Last year  John Hind and I
>> > wrote a module called "xtable" containing a function block.move
>> > such that when e>=f,
>> > block.move(a1,f,e,t)
>> > does exactly what the above definition of
>> > table.copy(a1,f,e,t)
>> > does. So I should be very pleased. However, I am not delighted
>> > by an optional argument preceding a non-optional one. It violates
>> > my sense of conceptual integrity.
>> >  <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> You know, maybe the resolution is to define separate move() and copy()
>> functions, where move() doesn't accept a destination, and copy()
>> requires one.
>> /s/ Adam
> But my read of the documentation tells me that the original values remain.
> Is that not the case? If it is, then move is more confusing, to me.
If the destination range overlaps the source range, you'll see why
it's a "move" operation.