DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Nov 11 18:15:13 UTC 2019

On Monday, November 11, 2019 11:03:35 AM MST Uknown via Digitalmars-d wrote:
> The problem is that once the slice is created, there's no way to
> know how the underlying memory was allocated. And if you want to
> append to the slice, then that's hard. Because there's no way to
> append generically in the language without the GC. Don't get me
> wrong, I think this DIP is the wrong solution. But there is an
> issue to be addressed. We need a way to be able to append without
> invoking the GC. I personally think std.experimental.allocators +
> some other associated language modifications are the way forward.

If you want to append to a dynamic array without using the GC, then just
allocate a new block of memory with malloc or whatever, copy the elements
from the dynamic array into it along with the elements being appended, slice
that block of memory, and assign that dynamic array to the first one. Of
course, you then have to code worrying about when it's safe to free that
memory, but if your code needs something like reference counting to manage
the memory, then it probably shouldn't be passing around dynamic arrays
anyway. Dynamic arrays which are slices of malloc-ed memory or static arrays
or whatnot work just fine so long as the code that does the slicing can know
when the dynamic arrays which are slices of that memory go out of scope so
that it can know when it's safe to free that memory, but if the dynamic
arrays being passed around in a way that the code doing the allocating can't
know when that memory isn't referenced anymore, then dynamic arrays are a
bad fit - and that's the case whether this DIP is accepted or not. If the
dynamic arrays are being passed around in a way that you don't know what
their lifetimes are, then they need to be GC allocated.

- Jonathan M Davis

More information about the Digitalmars-d mailing list