On Tuesday, 12 November 2019 at 17:09:30 UTC, Jab wrote:
> On Tuesday, 12 November 2019 at 12:30:42 UTC, Dukc wrote:
>> This DIP in it's current form would cause so much damage that if we fall behind because we won't do it, so be it.
>
> It is going to fall behind either way. This DIP focuses on falling behind Rust/C++ safety with manual memory management. But it completely ignores falling behind on simplicity/easy of use/unrestricted use with other languages that have a GC. The focus seems to only be on Rust/C++ lately. By trying to be safe with manual memory management you lose what the GC offers, this is in part due to the fact that GC pointers and malloc pointers are indistinguishable. It's a clash between two different ideologies that don't mix well.

D will fall behind in terms of stability. The language is 20 years old. It shouldn't be breaking the thousands and thousands of lines of code I've already written unless we're moving to D 3.0 over a period of several years. It's hard to see how the language recovers from making a move like this with no planning and no communication. I don't see how anyone could recommend using D after something like this, except maybe to people you really don't like and aren't your boss.

On Tuesday, 12 November 2019 at 15:59:57 UTC, jmh530 wrote:
> [snip]
>
>     @disable T[] opBinary(string op)(U rhs)
>         if (op == "~")
>     {
>         return data ~ rhs;
>     }
>
>     @disable T[] opBinary(string op)(U[] rhs)
>         if (op == "~")
>     {
>         return data ~ rhs;
>     }
>
> [snip]

Small error here
T[] opBinary
should be
T opBinary

On Tuesday, 12 November 2019 at 17:25:06 UTC, Jab wrote:
> This would be a memory leak, not memory corruption:
>
>   int[] slice = cast(int*)malloc(10 * int.sizeof)[0 .. 10];
>   slice ~= 1;
>   free(slice.ptr); // Oops!

Depends on the implementation of the garbage collector and C free.

If it frees the beginning of block that the GC has allocated using malloc then it would indeed cause memory corruption as soon at somebody else get the same block from malloc.

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

I am against it.

1. One of D's main selling points to me is productivity. We currently do not have the machinery in place to be as productive without the GC as with it. For example std.allocator is still experimental and there seems to be no movement on that front.

First put the alternatives in place in the meantime there is @nogc.

2. @nogc

3. If we remove arrays the language has no useful builtin/included container anymore. std.container is no alternative, e.g.: https://issues.dlang.org/show_bug.cgi?id=13791

On 12.11.19 18:09, Jab wrote:
> On Tuesday, 12 November 2019 at 12:30:42 UTC, Dukc wrote:
>> This DIP in it's current form would cause so much damage that if we fall behind because we won't do it, so be it.
> 
> It is going to fall behind either way. This DIP focuses on falling behind Rust/C++ safety with manual memory management. But it completely ignores falling behind on simplicity/easy of use/unrestricted use with other languages that have a GC.

I agree with this.

> The focus seems to only be on Rust/C++ lately. By trying to be safe with manual memory management you lose what the GC offers, this is in part due to the fact that GC pointers and malloc pointers are indistinguishable.

That's why the language needs to provide tools like borrowing, such that libraries can easily implement @trusted smart pointers that carry around allocator/ownership information. In @safe code, any accessible raw pointer always has to have unlimited lifetime. (In Rust, raw pointers are entirely inaccessible in safe code, because Rust has no built-in GC.)

> It's a clash between two different ideologies that don't mix well.

I don't agree with this. We can have both. We can enforce mutable aliasing constraints for memory accessible through shared, e.g., tracing GC-owned, pointers using runtime checks. (Rust also does this if you want to mutate memory through shared, e.g., reference counted, pointers.)

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":

This review round is now officially terminated. The DIP author has withdrawn the DIP from consideration. I've marked the DIP as Withdrawn and summarized the review, as well as the author's reason for withdrawal:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1025.md

I've also updated the DIP process documentation to describe the Withdrawn status:

https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md#withdrawn-and-superseded-dips

On 13.11.19 10:07, Mike Parker wrote:
> 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":
> 
> This review round is now officially terminated. The DIP author has withdrawn the DIP from consideration. I've marked the DIP as Withdrawn and summarized the review, as well as the author's reason for withdrawal:
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1025.md
> 
> I've also updated the DIP process documentation to describe the Withdrawn status:
> 
> https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md#withdrawn-and-superseded-dips 
> 

Thanks!

On Wednesday, November 13, 2019 2:07:04 AM MST Mike Parker via Digitalmars-d wrote:
> 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":
> This review round is now officially terminated. The DIP author has withdrawn the DIP from consideration. I've marked the DIP as Withdrawn and summarized the review, as well as the author's reason for withdrawal:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1025.md
>
> I've also updated the DIP process documentation to describe the Withdrawn status:
>
> https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md#withdraw n-and-superseded-dips

Thank you, Walter.

- Jonathan M Davis