On Borrow Checking

[Timon Gehr]

On 4/29/25 19:12, Walter Bright wrote:
> I caveat my remarks with although I've have studed the Rust 
> specification, I have not written a line of Rust code.
> 
> I was quite intrigued with the borrow checker, and set about learning 
> about it. While D cannot be retrofitted with a borrow checker, it can be 
> enhanced with it. A borrow checker has nothing tying it to the Rust 
> syntax, so it should work.
> 
> So I implemented a borrow checker for D, and it is enabled by adding the 
> `@live` annotation for a function, which turns on the borrow checker for 
> that function. There are no syntax or semantic changes to the language, 
> other than laying on a borrow checker.
> 
> Yes, it does data flow analysis, has semantic scopes, yup. It issues 
> errors in the right places, although the error messages are rather basic.
> 
> In my personal coding style, I have gravitated towards following the 
> borrow checker rules. I like it. But it doesn't work for everything.
> 
> It reminds me of OOP. OOP was sold as the answer to every programming 
> problem. Many OOP languages appeared. But, eventually, things died down 
> and OOP became just another tool in the toolbox. D and C++ support OOP, 
> too.
> 
> I predict that over time the borrow checker will become just another 
> tool in the toolbox, and it'll be used for algorithms and data 
> structures where it makes sense, and other methods will be used where it 
> doesn't.
> 
> I've been around to see a lot of fashions in programming, which is most 
> likely why D is a bit of a polyglot language :-/
> 
> I can also say confidently that the #1 method to combat memory safety 
> errors is array bounds checking. The #2 method is guaranteed 
> initialization of variables. The #3 is stop doing pointer arithmetic 
> (use arrays and ref's instead).
> 
> The language can nail that down for you (D does). What's left are memory 
> allocation errors. Garbage collection fixes that.

I am fully on board with your high-level fundamentals here.

However, I do not agree that `@live` really lives up to them. It's a 
borrow-checking-inspired linting tool for primarily `@system` code. It 
is not the kind of innovative tool people are likely to expect to find 
in the toolbox going forward.

At least my expectation would be that this is a borrow checker that 
plays nice with a language supporting memory safe mutable aliasing while 
providing memory safety guarantees for `@nogc` code when it is used.