I don't like slices in D

[Adam D. Ruppe]

On Thursday, 17 October 2013 at 19:23:37 UTC, Vitali wrote:
> I'm not accusing D having a bug here. I'm saying that in my 
> eyes a reallocation of the array referenced by the slice is not 
> useful, when capacity is still available.

There is no capacity available for the binary concatenation like 
that.

Given this:
   arr = arr[0..index] ~ arr[index+1..$];

arr[index] is, as far as this function can tell anyway, still in 
use. The concat operator never overwrites in-use data.

Consider this example:

int[] a = [1,2,3,4];
void foo(int[] b) {
    int[] c = b ~ 4;
}

foo(a[0 .. 2]);


Surely you wouldn't expect a == [1,2,4] now. But, that's what 
would happen if your function remove function didn't allocate!

a[0 .. 2] would become [1,2] with a capacity of 4, because that's 
the original length.

Then b ~ 4 sees that there's capacity, and then appends in place, 
writing b.length++; b[3] = 4;

but assert(&b[3] is &a[3]), so that just overwrote a's data. But 
since b and c are both local variables, that's certainly not what 
you intended.

Your example is a little less clear, since it takes the slice by 
reference, but it is still the same idea: there might be other 
slices to that same data that should not be overwritten.

A new allocation is the only way to be sure.



If you want to overwrite it though, your remove function can just 
copy the data itself without reallocation.

>   "Slicing does not copy the slice's data. It creates a new 
> slice value that points to the original array. This makes slice 
> operations as efficient as manipulating array indices."

D does slicing the same way. Your problem is with 
appending/concatenating.