Borrow Checking and Ownership Transfer

[Derek Fawcus]

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.

I can't say I'm 100% comfortable with these things, but anyway:

A characteristic of affine and linear types is that they can be 
'used'/'consumed' at most one, with linear also being 'used' at 
least once.  Hence linear types must be 'used'.

This has some awkwardness in how that behaviour is then 
experienced by the programmer.

So Rust has something which is a form of affine types, but the 
borrowing allows one to make use of the type without consuming 
the value.  i.e. a use is not deemed a 'use'/'consumption'.

This 'borrowing' creates a restricted form of pointer, possibly 
mutable, and the checker is then validating / proving a set of 
constraints for how such borrowed references may be handled.

I view this sort of thing (along with the many different forms of 
pointer which Cyclone had) as completely different to the forms 
of near/far/huge/segment pointer which were available in various 
DOS compilers, and that (IMO) doesn't make for a sensible 
comparison.

Certain modern languages already have multiple forms of pointer 
(nullable, non-null, fat, thing, with and without arithmetic) and 
those do not create the same issues for the programmer as the DOS 
style pointers did.

D itself already has 3 different types of pointer: references, 
pointers, arrays/slices.

I don't see adding additional types as an issue, other then 
syntactical issues.  Obviously there will be implementation 
issues for the compiler, but depending upon the presented form, I 
do not see a reason why this should result in user issues.