On Wednesday, 11 November 2020 at 13:30:16 UTC, Simen Kjærås
wrote:
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.
No... Not true. But either way, D and Golang only have simple
windows onto memory rather than dynamic array ADTs. That is bad
for correctness, static analysis and ownership modelling. A
simple choice, plausible for libraries, but bad for application
code. If D is going to support non-GC code well, it has to change
this. C++ got this right btw, where slices can only decrease in
size.
Then again, extending arrays is generally a bad idea for
performance in all languages... So try to avoid increasing size
after initial building.
