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

Walter Bright newshound2 at digitalmars.com
Mon Nov 11 21:41:14 UTC 2019

On 11/11/2019 5:13 AM, Dennis wrote:
> On Monday, 11 November 2019 at 11:26:49 UTC, Nicholas Wilson wrote:
>> is functional identical, thus any issues present in 2 are also present in 1. 
>> The suggestion that doing so in a loop would create more garbage is false as 
>> it is functionally identical.
> There is a difference: a = a ~ b is guaranteed to make a copy while a ~= b might 
> just use spare capacity of the memory that slice `a` refers to.
> https://dlang.org/spec/arrays.html#array-concatenation

That's right. I had overlooked that.

> This is what the dead/alive example is supposed to express.
> It is still true however that the rationale is not very convincing.
> The first example indeed doesn't show any benefits of the DIP:
> ```
> int[] slice = cast(int*)malloc(10 * int.sizeof)[0 .. 10];
> slice = slice ~ 1; // now guaranteed to make a copy
> free(slice.ptr); // Still oops
> ```

Imagine these 3 lines are spread out over a large code base.

> The following claim in the DIP is also unsubstantiated:
>> This change is a necessary part of D evolving towards being memory safe 
>> without using
>> a GC.

Memory safety cannot be achieved without control over who is the owner of memory.

> I would like to see an example of memory corruption in `@safe` code that can 
> happen because of slice appending.

   @trusted void myfree(void* p) { free(p); }

More information about the Digitalmars-d mailing list