Borrow Checking and Ownership Transfer

[Richard (Rikki) Andrew Cattermole]

On 10/05/2025 7:15 AM, jmh530 wrote:
> On Friday, 9 May 2025 at 18:28:11 UTC, Richard (Rikki) Andrew Cattermole 
> wrote:
>> On 10/05/2025 5:17 AM, jmh530 wrote:
>>> To your point about being a property of a pointer, the alternative 
>>> approach is to introduce a reference that is borrow checked. Yes, it 
>>> results in additional pointer types, but if that's the approach that 
>>> Rust ultimately relies on and it's the only way to achieve what we 
>>> want, then it's what should be done.
>>
>> I want to touch upon this because its misunderstood quite widely 
>> regarding the difference between Rust's borrow checker and ownership 
>> transfer system.
>>
>> The borrow checker loosens restrictions placed upon you by the 
>> ownership transfer system to give strong guarantees of aliasing and 
>> lifetimes. If you did not have the borrow checker, the ownership 
>> transfer systems restrictions would make things absolutely impossible 
>> to work with.
>> [snip]
> 
> Not sure I completely follow everything here, but is your point that to 
> actually do what Rust is doing we need the ownership/borrowing system 
> plus borrow checking?

Strictly speaking no.

What you need is escape analysis with relationship strengths.

```d
struct Owner {
     int* borrow() @escape(return^) { ... }
}

Owner owner = ...;
int* ptr = owner.borrow;
owner = Owner.init; // Error
```

The escape attribute there, upgrades the escape to protecting the this 
pointer for as long as the borrow exists.

DIP1000 has two relationship strengths, for this we need a third.

This triggers the borrow checking aspect to escape analysis.
Without it, it can't trigger per variable.

The main problem is how costly the data flow analysis of doing this is, 
to an extent that models enough code to both be useful and fast.

I think I've solved this part of the problem, and am currently 
implementing the first portion of it up to a proof of concept stage.