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); }
free(slice.ptr);
More information about the Digitalmars-d
mailing list