Is borrow checker the right thing for D?

IGotD- nise at nise.com
Thu Aug 15 19:53:59 UTC 2019


This is regarding the blog post

https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

and the associated DIPs.

What I'm worried about here is how this change would change the 
aesthetics and usability of D. Right now it is Java like, the 
garbage collector takes care of the memory and you can focus on 
being productive. Rust is a fad right now with its borrow checker 
memory model, but I think it is a fad because it is too limiting. 
The irony of the Rust model is that I often see people revert to 
reference counted objects when they cannot satisfy the borrow 
checker. Satisfying the borrow checker often makes you rethink 
the algorithm and sometimes that isn't even possible.

However, if the borrow checker is a step towards transparent and 
solid reference counting, then it would be a good thing. Why 
isn't reference counting considered as the automatic memory 
management in D? It is easy to understand, it fits with nearly 
all existing algorithms, it fits well with multi threading, it 
has no GC stalls. I would rather use the static analysis for the 
reference counting, for example optimizing away unnecessary 
increase/decreases of the RC.

There is a reason I use D and not Rust and that is that D is not 
Rust. I rather have the more pragmatic Java way of doing memory 
management. When I want to think about it, I'll just use manual 
memory management.

What do you think about refocusing the memory management efforts 
towards solid RC instead?


More information about the Digitalmars-d mailing list