Prototype of Ownership/Borrowing System for D
dkorpel at gmail.com
Sun Nov 24 12:30:27 UTC 2019
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: 
> 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
Or maybe it will, once your entire code base has transitioned to
@live, and you somehow fixed the issue of mixing memory pools
? But then code that is made to work with the garbage
collector will be crippled with overly strict aliasing rules from
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  and given the fact
that DIP 1021 has been accepted , 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" ,
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. ), 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
More information about the Digitalmars-d