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

Patrick Schluter Patrick.Schluter at bbox.fr
Tue Nov 12 07:54:31 UTC 2019

On Monday, 11 November 2019 at 21:41:14 UTC, Walter Bright wrote:
> 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 thought the GC knows if the memory is in its control or not? 
Why not prohibit the concatenation after the GC checked if it is 
memory it has no view over. That slice was allocated outside or 
points on the stack so stop with an error. It's not compile time, 
but better than nothing, but doesn't break all the apps that want 
to live a simple life of GC memory handling. If I had wanted to 
make my programmers life difficult I would have chosen Rust or 

>> 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);

cheating doesn't count. @trusted in the same vein ad casting, is 
explicit security overriding, you get what you called for.

More information about the Digitalmars-d mailing list