On Borrow Checking

[Luna]

On Tuesday, 29 April 2025 at 17:12:41 UTC, 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.

My personal opinion on the matter has softened a bit over time. I 
do think @live could overall be a nice addition to the language. 
Much like how @nogc is an opt in, there are cases where opting in 
to borrow checking would be interesting. So as an opt-in 
attribute I’d not mind it being in the language; I’m only opposed 
to it being enforced. My strong feelings in the past was mainly 
down to that. Didn’t want to end up having it forced on me 
everywhere. As long as dlang keeps its own identity and doesn’t 
try to become rust, I at least think it’d be an ok change 
nowadays.