Ownership and Borrowing in D

[Timon Gehr]

On 17.07.19 22:59, Walter Bright wrote:
> 
> Any competing system would need to not be 'opt-in' on a type by type 
> basis. I.e. the central feature of an @live function is the user will 
> not be able to write memory unsafe code within that function.

Those two things are not the least bit at odds with each other. You only 
need to do the additional checks for types that actually need it. (And 
there you need to _always_ do them in @safe code, not just in 
specially-annotated "@live" functions.) A dynamic array of integers that 
is owned by the garbage collector doesn't need any O/B semantics. A 
malloc-backed array that wants to borrow out its contents needs to be 
able to restrict @safe access patterns to ensure that the memory stays 
alive for the duration of the borrow.

Furthermore, making built-in types change meaning based on function 
attributes is just not a good idea, because you will get needless 
friction at the interface between functions with the attribute and 
functions without.

Anyway, it makes no sense to have a variable of type `int*` that owns 
the `int` it points to (especially in safe code), because that type 
doesn't track how to deallocate the memory.

Ownership and borrowing should be supported for user-defined types, not 
raw pointers. Rust doesn't track ownership for built-in pointers. In 
Rust, raw pointer access is unsafe.