On Borrow Checking

[Manu]

On Wed, 30 Apr 2025 at 03:16, Walter Bright via Digitalmars-d <
digitalmars-d at puremagic.com> 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.
>

On a slight tangent; why do I need to attribute the function at all for it
to check `scope` args don't escape?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20250502/70f43932/attachment.htm>