DIP 1025--Dynamic Arrays Only Shrink, Never Grow--Community Review Round 1
Timon Gehr
timon.gehr at gmx.ch
Tue Nov 12 18:00:29 UTC 2019
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.)
More information about the Digitalmars-d
mailing list