Prototype of Ownership/Borrowing System for D

[Walter Bright]

On 11/23/2019 3:40 PM, Timon Gehr wrote:
> I don't understand why 
> this is not a concern for _your_ designs, which freely admit to being 
> uncheckable and unsound. You can't say "@safe means memory safe and this is 
> checked by the compiler" and at the same time "@live @safe relies on unchecked 
> conventions to ensure memory safety across the @live boundary".

All languages that have an "unsafe" annotation rely on unchecked conventions 
when the boundary is crossed.


> I don't think this is the case. The GC-allocated raw pointer allows aliasing 
> while @live does not allow aliasing. They have incompatible aliasing 
> restrictions. It's like having a mutable and an immutable reference to the same 
> memory location.

If I may sum this up, it is you wish to not follow O/B rules in @live functions 
when you've got a GC pointer. I suspect it is possible to segregate such 
operations into separate, non- at live functions, and I concede that you'll find 
this inconvenient.

In your scheme, this issue is resolved by distinguishing the two by annotating 
the non-GC pointers with `scope`.


> What about the fact that it is _optional_ for a /caller/ to respect the smart 
> pointer's desired ownership restrictions? That's very restrictive for the smart 
> pointer! It won't be able to provide @safe borrowing functionality.

I understand that the salient difference between your scheme and mine is you 
attach it to the pointer type while mine attaches it to the function. Pretty 
much all of this discussion is about consequences of this difference, so I don't 
think it is necessary to go through it point-by-point agreeing with you on those 
consequences.

But yours has problems, too, so the question is which method is better?

Some problems:

1. Doesn't seem to be a way to prevent un-scope pointers from existing and being 
unsafe.

2. The splitting pointers down the middle into two categories: scope and 
un-scope. This is a very intrusive and drastic change. The only saving grace of 
the existing `scope` and `return` annotations is the compiler can infer the vast 
bulk of them. Will people accept manually adding `scope` to a big chunk of their 
types? I don't know.