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

[Steven Schveighoffer]

On 11/11/19 12:12 PM, Ola Fosheim Grøstad wrote:
> On Monday, 11 November 2019 at 17:00:07 UTC, Steven Schveighoffer wrote:
>> No, you are misunderstanding a lot here.
> 
> This is nitpicking.
> 

Sorry, I'm not sure why it's nitpicking. The example shown does not show 
what the author wanted it to show.

When you have a function:

void f(int x[]) @safe pure nothrow
{
     x ~= 0;
}

There is no way to call that function in a way that will break safety, 
or alter any external data. It's pure, only the shallowly passed in 
slice is affected, nothing outside. This is truly a misunderstanding by 
the author (Uknown) of what a slice actually is.

The original example in the DIP shows more of a problem, but @nogc is 
certainly a solution there, which is why people are bringing it up.

> If you are going to have a good story with interfacing with C++ 
> libraries and frameworks... you don't want this to fail accidentally:
> 
> ownerpointer = normalize(initialize(allocate()))
> 
> Where normalize is a D function that calls other GC library code that is 
> well-behaving, except the one that accidentally grows the slice because 
> it works in the library-author's pure GC code.

True, GC-using code could be valid to call if it doesn't affect your 
type. But @nogc IS a valid way to use slices and ensure that they never 
use the GC to grow.

But in fact, a better solution is to make sure the TYPE prevents it, and 
we absolutely have the mechanisms today to do this. An opt-in type 
(ironically, such as Array), would be sufficient to make sure you can 
still call gc-using code, without mucking with your type's ability to 
free the original pointer.

If the DIP said it wanted to introduce a type that enforces it will 
always point to the resource that is managed, that would be fine. It 
just can't overtake T[] to mean that. It's way way too disruptive. I'd 
be fine with new syntax as well (like T[new] or whatnot).

-Steve