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

[Sebastiaan Koppe]

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/1b525ec4c914c06bc286c1a6dc93bf1533ee56e4/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.

I understand where this proposal comes from, but it would 
certainly cause a lot of breakage and it would cripple the 
universal feature common to all programming languages, arrays. 
Without filling the void this proposal leaves behind, I don't see 
any support for it.

I would personally look at the conflation of dynamic arrays and 
slices. If you could somehow separate the 2 concepts and THEN 
constrain slices to only be able to shrink, that might work. (or 
keep them conflated but make borrowed slices non appendable.) (or 
make the implicit explicit by somehow requiring `.array` before 
appending).

On the other hand, the fact that they are conflated also brings 
benefits, and you certainly don't want to loose them. It is a 
tough nut to crack.

OT:

In general I agree with the sentiment D's language features 
oftentimes depend too much on an all-knowing garbage collector. 
Maybe there is a way that behaviour could be made customisable 
for people who need that, instead of having everyone bear the 
costs. (e.g. I have done a lot of betterC programming lately, and 
while I can use my own custom allocators, things like closures 
still depend on a GC.)