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 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.

On Tuesday, 29 April 2025 at 20:40:51 UTC, Timon Gehr wrote:
> On 4/29/25 19:12, Walter Bright wrote:
>> [...]
>
> 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.
>

Hmm, for some reason I thought @live only worked with @safe code, like DIP 1000, but I when I scan over the @live documentation I don’t see any reference to @safe.

On 4/29/2025 1:40 PM, Timon Gehr wrote:
> 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.

I'm aware that you and I disagree on the details! But I'm reluctant to invest more time on it given the decided general lack of interest in it.

P.S. maybe we can have a great discussion on it at Dconf! I was very pleased with how our rvalue discussion went last time.


> 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.

On 4/29/2025 3:46 PM, jmh530 wrote:
> Hmm, for some reason I thought @live only worked with @safe code, like DIP 1000, but I when I scan over the @live documentation I don’t see any reference to @safe.

It works with both.

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.

On Tuesday, 29 April 2025 at 23:40:56 UTC, Walter Bright wrote:
> On 4/29/2025 1:40 PM, Timon Gehr wrote:
>> 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.
>
> I'm aware that you and I disagree on the details! But I'm reluctant to invest more time on it given the decided general lack of interest in it.
>
> [snip]

I have flashbacks of the recent D hacker news thread where you said marketing isn't your strong suit...

You wrote a blog post on ownership and borrowing back in 2019 (https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/), but it has just a brief mention of @live. Would you want to expand your original post with an emphasis on @live, why to use it, and what it gets you?

Otherwise to your point about lack of interest, my recollection is that there has been a lot of discussion over the years about safe reference-counting, maybe and allocator-aware container libraries (I assume this is possible but limited in ways that people aren't happy about). And my sense is that DIP 1000 and @live haven't quite gotten us to the place where people want the language to be. That could be a driver to the lack of interest.

There are only so many hours in the day, and I'm sure people would prefer you polish some other features before focusing on this. But I don't think it is unwise to be thinking about these issues.

On 4/29/2025 6:26 PM, jmh530 wrote:
> You wrote a blog post on ownership and borrowing back in 2019 (https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/), but it has just a brief mention of @live. Would you want to expand your original post with an emphasis on @live, why to use it, and what it gets you?
> 
> Otherwise to your point about lack of interest, my recollection is that there has been a lot of discussion over the years about safe reference-counting, maybe and allocator-aware container libraries (I assume this is possible but limited in ways that people aren't happy about). And my sense is that DIP 1000 and @live haven't quite gotten us to the place where people want the language to be. That could be a driver to the lack of interest.

We spent a considerable time thinking about safe reference-counting. We could not find a way around its considerable performance penalties, and its unsafety, and so abandoned it.

On 30/04/2025 11:40 AM, Walter Bright wrote:
> I'm aware that you and I disagree on the details! But I'm reluctant to invest more time on it given the decided general lack of interest in it.

I've been suspecting for a couple of months, that you've been feeling like that you've done your time on it, which this confirms.

If we're getting a different DFA based language feature solution, it'll be because somebody else implemented it.

It won't be come as any surprise that the result of this has been me implementing what I've been calling the fast DFA :)

On 30/04/2025 2:58 PM, Walter Bright wrote:
> On 4/29/2025 6:26 PM, jmh530 wrote:
>> You wrote a blog post on ownership and borrowing back in 2019 (https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/), but it has just a brief mention of @live. Would you want to expand your original post with an emphasis on @live, why to use it, and what it gets you?
>>
>> Otherwise to your point about lack of interest, my recollection is that there has been a lot of discussion over the years about safe reference-counting, maybe and allocator-aware container libraries (I assume this is possible but limited in ways that people aren't happy about). And my sense is that DIP 1000 and @live haven't quite gotten us to the place where people want the language to be. That could be a driver to the lack of interest.
> 
> We spent a considerable time thinking about safe reference-counting. We could not find a way around its considerable performance penalties, and its unsafety, and so abandoned it.

I'm still trying to solve it with my DFA work, however I do have a backup plan.

1. Ban all pointers. System handles and with that coroutines/fibers are all @trusted and @system so it doesn't effect them. Anything else should be using the GC and therefore unaffected by this restriction.

2. Let the backend handle optimizations. Reference counting primitives are improving (at least in LLVM). Worst case scenario, we have the exact same performance as we do now, but with a better user experience.