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

Uknown sireeshkodali1 at gmail.com
Mon Nov 11 18:03:35 UTC 2019


On Monday, 11 November 2019 at 17:00:07 UTC, Steven Schveighoffer 
wrote:
> On 11/11/19 11:47 AM, Uknown wrote:
>> A lot of people are bringing it up, so I'll bite. The problem 
>> with @nogc is that it doesn't cover all cases. Imagine the 
>> code given in the DIP like this instead:
>> 
>> ---lib.d
>> 
>> void f(int x[]) @safe pure nothrow
>> {
>>      x ~= 0;
>> }
>> 
>> ---main.d
>> 
>> void main() @safe
>> {
>>      import lib: f;
>>      import std.container : Array;
>> 
>>      Array!int x = [0, 1, 2, 3, 4];
>> 
>>      f(slice);
>>      // x's dtor will try to free an invalid pointer
>> }
>> 
>> Clearly here main does something that seems safe on the 
>> surface. But in actuality it is clearly unsafe code. And its 
>> hard to verify, because main and the libraries used are 
>> written by completely different people.
>
> No, you are misunderstanding a lot here.
>
> 1. f(slice), there is no symbol slice, I think maybe you mean 
> x[]?

yes, my mistake

> 2. f's x is a *copy*, which means that appending to x here DOES 
> NOT AFFECT main's x at all. Main's x will destroy perfectly 
> fine, and all is well.

You're right, I shouldn't have used Array. I was just trying to 
point out how libraries could obscure such bugs. A different 
container with different semantics which exposes slices could 
cause issues.

> 3. If @nogc is added to main, then it won't compile, because f 
> cannot be @nogc. Which is quite the point people are making.
>
> -Steve

The problem is that once the slice is created, there's no way to 
know how the underlying memory was allocated. And if you want to 
append to the slice, then that's hard. Because there's no way to 
append generically in the language without the GC. Don't get me 
wrong, I think this DIP is the wrong solution. But there is an 
issue to be addressed. We need a way to be able to append without 
invoking the GC. I personally think std.experimental.allocators + 
some other associated language modifications are the way forward.


More information about the Digitalmars-d mailing list