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

[Jonathan M Davis]

On Monday, November 11, 2019 7:48:54 AM MST IGotD- via Digitalmars-d wrote:
> On Monday, 11 November 2019 at 10:27:26 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1025, "Dynamic Arrays Only Shrink, Never Grow":
> >
> > https://github.com/dlang/DIPs/blob/1b525ec4c914c06bc286c1a6dc93bf1533ee5
> > 6e4/DIPs/DIP1025.md
> >
> > All review-related feedback on and discussion of the DIP should
> > occur in this thread. The review period will end at 11:59 PM ET
> > on November 25, or when I make a post declaring it complete.
> >
> > At the end of Round 1, if further review is deemed necessary,
> > the DIP will be scheduled for another round of Community
> > Review. Otherwise, it will be queued for the Final Review and
> > Formal Assessment.
> >
> > Anyone intending to post feedback in this thread is expected to
> > be familiar with the reviewer guidelines:
> >
> > https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
> >
> > *Please stay on topic!*
> >
> > Thanks in advance to all who participate.
>
> "Enlarging a slice, using the append operator or by setting the
> .length property, makes use of the garbage collector. This
> fosters the incorrect notion that D slices require the GC."
>
> The title mentions arrays but the rest of the text is about
> slices.
>
> I need one clarification, this DIP regards slices not arrays? So
> an array is being able to be resized just as before. It's just
> that this will no longer apply for slices?
>
> If this only regards slices, then I think this is a sound change,
> even if it is breaking. A slice should not really know the
> underlying algorithm how the data is stored. It could be an
> array, it could be part of a buffer or a view into any other
> structure. Limiting the slice so that it cannot grow beyond its
> original boundaries makes sense.
>
> If this include arrays, that they aren't able to grow then I'm
> against this change but again it doesn't make any sense. Then it
> is not a dynamic array.

Dynamic arrays _are_ slices. T[] is a dynamic array which is a slice of a
block of memory which may or may not be GC-allocated. Some folks do try to
talk like dynamic arrays are the GC-allocated memory block that a slice
refers to, but that's not the definition used by the language. As far as the
language is concerned, T[] is a dynamic array no matter what memory it
refers to, and the language has no specific term for a memory block
allocated by the GC which is sliced by a dynamic array.

This DIP makes it so that it would no longer be possible to use any
operations on a dynamic array which would increase its size, whereas right
now those operations always work in code that isn't @nogc no matter what
memory the dynamic array is a slice of. It's just that in the case where the
dynamic array has no capacity to grow, you always get a reallocation.
Whether the dynamic array referred to GC-allocated memory or not is
irrelevant except that if the memory is not GC-allocated, there definitely
isn't room to grow the dynamic array in-place, whereas if it was
GC-allocated then there might be room to grow in-place. In either case, if
there isn't room to grow in-place, then the GC allocates a new memory block,
copies the elements into the new memory block, and alters the dynamic array
to point to the new memory block.

- Jonathan M Davis