On Wednesday, 11 November 2020 at 10:17:09 UTC, zack wrote:
I am new to D. Appending to an array can lead to reallocation,
that's clear. But why is the "reference" b not changed
accordingly to the new position and still points to "old"
memory? Why is b not also changed when reallocating array a and
the old data getting invalid/freed?
auto a = [55,10,20];
auto b = a;
a ~= [99,99,99,99,99,99];
a[0] = 1;
assert(b[0] == 1); // could fail
(similar to p.103-104 in "The D Programming language")
The short answer is 'because that's how we've chosen to define
it'. A more involved answer is that changing every reference is
prohibitively expensive - it would require the equivalent of a GC
collection on every reallocation, as references to the array
could exist anywhere in the program, be that on the stack, heap,
even on other threads. That's the performance side of it.
Another heavy argument is 'can you make it behave the other way?'
Currently, that's simple: use a pointer to a slice (T[]*), and
share that around. I don't see how I would get the current
behavior if reallocation caused reassignment of all references
(though admittedly I haven't thought too much about it).
Next up: does b, ending on the same element as a, refer to the
whole length of a (i.e. should b's length be reassigned when a is
reallocated?), or is it a slice only referencing the first three
elements? Either choice is going to be unexpected in some cases.
All in all, there's many reasons to choose the behavior D has
chosen. There are some drawbacks, but I feel it's the right
choice.
--
Simen
