On Monday, 11 November 2019 at 13:26:56 UTC, Adam D. Ruppe wrote:
> [snip]
>
> It should probably just be
>
> int[] slice = (cast(int*)malloc(10 * int.sizeof))[0 .. 10];
>
>
> Since the type certainly should be int[], and it will compile.

Ah, thanks.

So I could probably re-write this as

```
    int* data = cast(int*)malloc(10 * int.sizeof);
    int[] slice = data[0 .. 10];
```

So maybe the issue is with being able to slice arbitrary pointers? I don't know...

It all seems tied in to the ability to conflate a malloc'ed slice with a GC'ed slice. If anything, I don't think it should be easy to do this.

On Monday, 11 November 2019 at 10:27:26 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1025, "Dynamic Arrays Only Shrink, Never Grow":
>
> https://github.com/dlang/DIPs/blob/1b525ec4c914c06bc286c1a6dc93bf1533ee56e4/DIPs/DIP1025.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on November 25, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

"Enlarging a slice, using the append operator or by setting the .length property, makes use of the garbage collector. This fosters the incorrect notion that D slices require the GC."

The title mentions arrays but the rest of the text is about slices.

I need one clarification, this DIP regards slices not arrays? So an array is being able to be resized just as before. It's just that this will no longer apply for slices?

If this only regards slices, then I think this is a sound change, even if it is breaking. A slice should not really know the underlying algorithm how the data is stored. It could be an array, it could be part of a buffer or a view into any other structure. Limiting the slice so that it cannot grow beyond its original boundaries makes sense.

If this include arrays, that they aren't able to grow then I'm against this change but again it doesn't make any sense. Then it is not a dynamic array.

On Monday, 11 November 2019 at 14:48:54 UTC, IGotD- wrote:
> I need one clarification, this DIP regards slices not arrays? So an array is being able to be resized just as before. It's just that this will no longer apply for slices?

Maybe this article will help:
https://dlang.org/articles/d-array-article.html#responsibility

> So where is the true dynamic array type in D? It's hidden by the runtime, and in fact, has no formal type. Slices are good enough, and as it turns out, the runtime is smart enough about what you want to do with the data, that you almost never notice dynamic arrays are missing as a full-fledged type. In fact, most D coders consider the D slice to be the dynamic array type -- it's even listed as a dynamic array type in the spec! The lack of ownership is very subtle and easy to miss.

On Monday, 11 November 2019 at 14:56:22 UTC, Dennis wrote:
> On Monday, 11 November 2019 at 14:48:54 UTC, IGotD- wrote:
>> I need one clarification, this DIP regards slices not arrays? So an array is being able to be resized just as before. It's just that this will no longer apply for slices?
>
> Maybe this article will help:
> https://dlang.org/articles/d-array-article.html#responsibility
>
>> So where is the true dynamic array type in D? It's hidden by the runtime, and in fact, has no formal type. Slices are good enough, and as it turns out, the runtime is smart enough about what you want to do with the data, that you almost never notice dynamic arrays are missing as a full-fledged type. In fact, most D coders consider the D slice to be the dynamic array type -- it's even listed as a dynamic array type in the spec! The lack of ownership is very subtle and easy to miss.

Does this mean if this DIP goes though, a "real" distinctive dynamic array implementation must be done in order facilitate the functionality that has previously been done by D-slices?

On Monday, 11 November 2019 at 15:00:50 UTC, IGotD- wrote:
> Does this mean if this DIP goes though, a "real" distinctive dynamic array implementation must be done in order facilitate the functionality that has previously been done by D-slices?

Reminds me of the old T[new] thing from like.... dconf 2007 or something. What's old is new again.

The Rationale of this DIP is lacking IMO.
It highlights a problem, that the DIP will fix, but doesn't explain the greater
context of the problem.
The last few DIPs started from a fairly low level IMO.
To me it is not clear where this journey should go.
What is the long term payoff for this pain?
Are we aiming for rust like memory management? C++ like? Python like?
Something in between?

I think this needs to addressed before this DIP can be discussed.

I know this pushes the bounds of the review guidelines, but I think this
DIP starts a journey in the wrong direction.
IMO D's problem is not the GC nor ~=.
I think it is the "wrong to assume" that manual memory management (mmm) should
play nice with the GC.
The GC should be the @safe default.
If you use mmm you made your bed, don't force me to reshuffle my GC bed.
I think mmm and safety are very hard to consolidate.
We should spend our resources on making range based, functional, programming
in combination with the GC @safe and easy.

Another valid way to solve the problem given in the rationale of the DIP would
be to disallow the use of malloc or the cast.

On Monday, 11 November 2019 at 15:11:32 UTC, Robert Schadek wrote:
> 
>
> Another valid way to solve the problem given in the rationale of the DIP would
> be to disallow the use of malloc or the cast.

malloc is also only allowed in @system code.

On Monday, 11 November 2019 at 15:24:48 UTC, jmh530 wrote:
> malloc is also only allowed in @system code.

Now I'm even less sure what this DIP tries to achieve in the long run.

On Monday, 11 November 2019 at 15:29:21 UTC, Robert Schadek wrote:
> Now I'm even less sure what this DIP tries to achieve in the long run.

The question isn't the allocation itself, but rather the slice.

void main() {
   int[5] buffer; // or malloc or whatever
   foo(buffer[]); // this is OK
}

@safe void foo(scope int[] a) {
   a ~= 0; // and this now reallocates on the GC
}



but i'd argue this is the *right* thing to do. and if you don't want the GC function, do @nogc on it, now it is a compile error.

If we were saying that T[] shouldn't have a ~= operator at all... well i can kinda see the point, you could use a container object instead.

But a lot of times the current behavior is perfectly sane. Like this example has no memory leak, no out of bounds access, and is convenient to use.

If anything maybe we should make @nogc more granular so like have independent @nosliceappend or whatever. But like meh.

On Monday, 11 November 2019 at 15:56:02 UTC, Adam D. Ruppe wrote:
I was not necessarily trying to make that point.

I was merely trying to say, that IMO, mmm should not be considered
a necessarily desirable concept, especially when @safety is the goal.

In other words, approxEqual(!mmm, "Less problems making D @safe")