Is borrow checker the right thing for D?

[Atila Neves]

On Saturday, 17 August 2019 at 12:09:19 UTC, Timon Gehr wrote:
> On 16.08.19 11:34, Atila Neves wrote:
>> But, right now, it's possible to corrupt memory in D without 
>> the compiler telling you,
>
> It's important to note that the reason why this happens is that 
> there is @trusted code that doesn't account for all ways @safe 
> code can access its interface. I.e., it's bad @trusted code, 
> and inexpressive type system, not unsound type system. The only 
> ways to fix this are
>
> 1) add more runtime checking to @trusted code and don't 
> directly expose mutable references where this is problematic.
> 2) give more type system tools to @trusted code to restrict how 
> @safe code may access its interface, so exposing mutable 
> references directly is valid in more circumstances.
>
>> and that's not a thing we want.
>
> None of the borrow/ownership proposals in the pipeline do 
> anything that would allow @trusted code to restrict the set of 
> possible access patterns from @safe code. They are a form of 
> Rust cargo cult.

So you've mentioned, but I'm afraid I didn't understand the 
argument (it didn't help it was over several emails). I would 
really appreciate an explanation of why you think the current 
proposals are inadequate, and what we could do instead. Thanks!