On Borrow Checking (page 5)

On 5/4/25 18:35, Dukc wrote: > On Sunday, 4 May 2025 at 11:02:27 UTC, Paul Backus wrote: >> >> This page is the first result on Google for "unsafe rust". The fact that you got this wrong shows very clearly that you have not done your homework on this topic. > > I think you're a bit too fast with your judgement here. > > While the unsafe keyword doesn't directly turn off the borrow checker, it does let you to work your way around it. I don't know exactly how, but I'm sure it's possible; it's a systems programming language after all. Most likely it involves calling some sort of unsafe typecasting function. I think this is what Walter means. Well, in unsafe Rust you can use raw pointers that are not subject to lifetime checks.

On Sunday, 4 May 2025 at 16:35:23 UTC, Dukc wrote:

On Sunday, 4 May 2025 at 11:02:27 UTC, Paul Backus wrote:

This page is the first result on Google for "unsafe rust". The fact that you got this wrong shows very clearly that you have not done your homework on this topic.

I think you're a bit too fast with your judgement here.

While the unsafe keyword doesn't directly turn off the borrow checker, it does let you to work your way around it. I don't know exactly how, but I'm sure it's possible; it's a systems programming language after all. Most likely it involves calling some sort of unsafe typecasting function. I think this is what Walter means.

No, you're giving Walter too much credit here.

In context, he is clearly trying to claim that the @live/non-@live distinction in D is analogous to the safe/unsafe distinction in Rust w.r.t. borrow checking--i.e., that both languages have a mode with borrow checking, and a mode without it. The difference--he claims--is that in Rust, the mode with borrow checking is opt-out, and in D, it's opt-in.

The actual difference between D and Rust's approach is that Rust has two separate kinds of pointers: references, which are borrow-checked (in both safe and unsafe code), and raw pointers, which aren't. In other words, whether borrow checking is done or not is decided on a type-by-type basis, not a function-by-function basis.

The fact that Walter is (apparently) unaware of these facts shows that he has clearly not "studied the Rust specification," as he claims.

3 days ago

Re: On Borrow Checking

Posted by Dukc
in reply to Walter Bright

Permalink

Dukc

Posted in reply to Walter Bright

Permalink

On Saturday, 3 May 2025 at 19:22:20 UTC, Walter Bright wrote:

You add:

@live:

at the beginning of your modules.

I would never seriously consider this.

It would mean I have to make all my @safe code @live before I can begin using the @trusted version of free without it being safewashing.

And thereafter I could never use any third party @safe/@trusted code that isn't verified to be @live correct. This includes Phobos.

Just dropping to @system/@trusted when doing manual memory management is far more practical regardless of the use case.

Because it is opt-in with D rather than opt-out in Rust, does not alter the fact that D has a borrow checker.

Most certainly we don't want to force existing @safe D code to adapt @live rules. Not even over an edition switch. In that you're right.

But ironically, our opt-out borrow checker does exactly this in a practical sense. Like I wrote above, you can only depend on @live for @safety if you use it everywhere. This is the worst of both worlds: not only do I have to make all my @safe code to use the borrow checker (as in Rust), I must manually make sure I don't have any non-@live @safe code around, unless I'm willing to manually review them like a @trusted function.

If the borrow checker is to be of any real use, we need some way to check where it is needed. So that code that does manual memory management will have to use @live (or ditch @safe), but your regular garbage-collected stuff won't.

On 5/4/2025 3:57 AM, Paul Backus wrote: > Even if you do this, you still cannot manually free memory in @safe code, like you can in Rust. Actually, you can in D. The borrow checker doesn't know anything about free'ing memory. What it does know is the ownership of the pointer transferred to the function, or not. That's all it needs to know. > Borrow checking, in itself, is not a useful feature--it's just a bunch of arbitrary hoops the programmer has to jump through. It is useful in Rust ONLY because of the additional safety analysis it enables. In D, the borrow checker does not enable any additional safety analysis, so why would the programmer ever want to jump through its hoops? The check it does is enforce the style of only one mutable pointer being live at a time, which prevents double frees. It enforces that a mutable pointer is not left dangling, which prevents omitted frees.

The point of the borrow checker is to ensure there is exactly one point of origin for a pointer and exactly one point of termination for it. In other words, one allocation and one free. More than one free is a memory safety bug, continuing to use a pointer after it is free'd is a memory safety bug, and never freeing a pointer is not a memory safety bug, but is still a bug. I also like it for aesthetic purposes, as it makes code more readable.

Forums