Prototype of Ownership/Borrowing System for D

[Dennis]

On Sunday, 24 November 2019 at 02:10:41 UTC, mipri wrote:
> There's not a choice between absolute perfect guarantees (with
> some other design) vs. a complete absence of guarantees (with
> this one). The choice is between language defaults, in how
> easily the guarantees can be defeated, in what you can expect
> of other people's code.

Walter's design has the explicit goal of giving 100% mechanically 
checkable memory safety for (limited) manual memory management.
Take for example this reply regarding a different proposal: [1]

> I haven't studied that. Is it a 100% [mechanically checkable 
> memory safety] solution? I know there's one being worked on for 
> C++, but it's an 80-90% solution.
>
> D needs to have a 100%, mechanically checkable, solution.
>
> We have 100% for transitive const and function purity. It's 
> hard to get code to pass, but worth it when one succeeds. The 
> Ownership/Borrowing solution is 100% which is what is appealing 
> about it.

But now it appears to be more and more a linting tool for @system 
code that catches some errors but doesn't give any guarantees at 
all.
Or maybe it will, once your entire code base has transitioned to 
@live, and you somehow fixed the issue of mixing memory pools 
[2]? But then code that is made to work with the garbage 
collector will be crippled with overly strict aliasing rules from 
@live.

The current path seems to go towards a three-way split of D 
projects between memory management styles:
- @safe for code like Java/C#
- @system for code like C/C++
- @live for code like Rust

It would be really cool if ownership and borrowing could work 
alongside the garbage collector instead of introducing this hard 
split called `@live` for every function.

And if this was all just an experiment to test the waters before 
creating a final, complete design, I would not be concerned. But 
the way it is described in the blog post [3] and given the fact 
that DIP 1021 has been accepted [4], it seems like Walter is 
already committed to this specific design which has been pointed 
out to be seriously flawed by Timon Gehr multiple times now.

Walter's attitude seems to be "We plug the holes one by one" [5], 
but I don't see any holes being plugged recently. The test cases 
in the pull request do not display any memory corruption. 
Examples on the news group often include a wrongly @trusted free 
function (e.g. [6]), which do not show anything.

While I am excited that @safe is being worked on, it is 
completely unclear to me how any of the recent developments 
contribute to @safe as a 100% mechanically checked memory safety 
solution. If we're going to downgrade @safe to a 80% memory 
safety solution relying on strong defaults and well-informed 
programmers, then the specification needs to be updated to 
reflect that.

[1] https://forum.dlang.org/post/qlvihc$24nk$1@digitalmars.com
[2] 
https://github.com/dlang/dmd/pull/10586/files#diff-e96b0b4865baa6204208527156832d3fR252
[3] 
https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
[4] 
https://forum.dlang.org/post/beselqdzploaeqfunzos@forum.dlang.org
[5] https://forum.dlang.org/post/qluqlv$c5m$1@digitalmars.com
[6] https://forum.dlang.org/post/qqckhn$1hss$1@digitalmars.com