<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 30 Apr 2025 at 03:16, Walter Bright via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I caveat my remarks with although I've have studed the Rust specification, I <br>
have not written a line of Rust code.<br>
<br>
I was quite intrigued with the borrow checker, and set about learning about it. <br>
While D cannot be retrofitted with a borrow checker, it can be enhanced with it. <br>
A borrow checker has nothing tying it to the Rust syntax, so it should work.<br>
<br>
So I implemented a borrow checker for D, and it is enabled by adding the `@live` <br>
annotation for a function, which turns on the borrow checker for that function. <br>
There are no syntax or semantic changes to the language, other than laying on a <br>
borrow checker.<br>
<br>
Yes, it does data flow analysis, has semantic scopes, yup. It issues errors in <br>
the right places, although the error messages are rather basic.<br>
<br>
In my personal coding style, I have gravitated towards following the borrow <br>
checker rules. I like it. But it doesn't work for everything.<br>
<br>
It reminds me of OOP. OOP was sold as the answer to every programming problem. <br>
Many OOP languages appeared. But, eventually, things died down and OOP became <br>
just another tool in the toolbox. D and C++ support OOP, too.<br>
<br>
I predict that over time the borrow checker will become just another tool in the <br>
toolbox, and it'll be used for algorithms and data structures where it makes <br>
sense, and other methods will be used where it doesn't.<br>
<br>
I've been around to see a lot of fashions in programming, which is most likely <br>
why D is a bit of a polyglot language :-/<br>
<br>
I can also say confidently that the #1 method to combat memory safety errors is <br>
array bounds checking. The #2 method is guaranteed initialization of variables. <br>
The #3 is stop doing pointer arithmetic (use arrays and ref's instead).<br>
<br>
The language can nail that down for you (D does). What's left are memory <br>
allocation errors. Garbage collection fixes that.<br></blockquote><div><br></div><div>On a slight tangent; why do I need to attribute the function at all for it to check `scope` args don't escape?</div><div>I do want to add `scope` to pointers and ref arguments, but I don't see any reason that I should have to attribute `live`... why isn't `scope` enough to enable escape analysis?</div></div></div>