On Mon, 16 May 2011 16:14:33 -0400, Timon Gehr <timon.g...@gmx.ch> wrote:
Steven Schveighoffer wrote:
On Mon, 16 May 2011 15:52:23 -0400, Mehrdad <wfunct...@hotmail.com>
wrote:
On 5/16/2011 12:53 PM, Timon Gehr wrote:
In fact I even need to take that back. In order to work correctly,
the
function would have to iterate downwards. It _is_ indeed buggy, and I
should stop emitting opinions when I'm short on time...
Andrei
Whoops, you are right:
void removeAt(T)(ref T[] arr, size_t index)
{
foreach (i, ref item; retro(arr[1 .. index+1]))
item = arr[i - 1];
arr = arr[1 .. $];
}
Timon
Wouldn't that stomp on the super-slice of arr, though?
As was pointed out on SO, the problem is actually always there: if
someone passes arr[0 .. $] to a function, it will look as if the
original array was passed, although it wasn't. Seems like it's a lot
uglier than I'd thought...
arr[0..$] shouldn't be an lvalue (it is, but I think that's a bug).
Therefore, you shouldn't be able to pass it as a ref argument (is this
in
bugzilla?).
-Steve
I think it is a little bit more subtle than "not lvalue", because you
actually
have to be able to do something like:
arr[0..2] = arr[3..5];
Where a slice appears on the left hand side of the assignment. (also
a[]=b[]).
ref is not required in those cases, the array can be passed by value (and
by value, I mean the pointer and length, not the data).
You only need the array to be an lvalue when you want the passed-in
array's pointer and length to be modified.
-Steve
