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.