I don't like slices in D

Vitali notavailable at mail.com
Thu Oct 17 12:23:36 PDT 2013


I didn't expect that you would doubt that the array gets 
reallocated. Here a code to test:

void appendElement(ref int[] arr, int x) {
	arr ~= x;
}

void removeElement(ref int[] arr, int index) {
	arr = arr[0..index] ~ arr[index+1..$];
}

void main() {
   int* arrPtr1;
   int* arrPtr2;
   int[] arr = [1, 2, 3];

   arr.reserve(7);       // Reserve capacity.
   arr.appendElement(4); // I don't want a realocation
   arrPtr1 = arr.ptr;
   assert(arr.capacity==7);
   arr.removeElement(1); // happen here,
   assert(arr.capacity==3);
   arr.appendElement(5); // but it happens.
   arrPtr2 = arr.ptr;

   assert(arr[1] == 3);
   assert(arr[2] == 4);
   assert(arr[3] == 5);
   assert(arrPtr1 != arrPtr2);  // different arrays <- here
}

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.

@Ali Çehreli: You are right, Go's slices consist of three 
members. I have read it, although I din't test the code. In 
http://blog.golang.org/go-slices-usage-and-internals is said:
   "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."

I repeat "[...] as efficient as manipulating array indices." In D 
this is not the case and can't imagine what purpose can it suit 
else.

@Meta and @David Eagen: My question is not about creating slices, 
but about make them shrink and grow without reallocating the 
referenced array.


More information about the Digitalmars-d mailing list