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

[Timon Gehr]

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