Prototype of Ownership/Borrowing System for D

[mipri]

On Saturday, 23 November 2019 at 23:40:05 UTC, Timon Gehr wrote:
> If you want @live to mean: "do these additional checks", that
> is fine, if people indeed want to write @system code with those
> checks without a guarantee that their code is safe if the
> checks pass.

It's a compile-time guarantee that a class of error can't occur
within the code so marked. If a non- at live caller makes use of
some @live code, and introduces his own errors, they're his
own error. @live remains in the language as a tool that the
calling code might use to gain the same protection. As it
expands in a code base, so shrink the places where these
errors may still be found.

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. This is why everyone doesn't say that
Rust has no real safety because you can always drop down an
unsafe {} block and do whatever you want, and why Rust hasn't
gotten a reputation as an unsafe language even as bugs are
occasionally found in the unsafe blocks of its standard
library.  unsafe {} isn't the default; since you have to opt
into errors it's very easy to avoid opting in; and you can
expect that other people will make sparing use of unsafe {}.

In D, @system is the default and you have to opt in to various
protections, so it's very different language, but @live is in
line with that language. I think it's also in line with any
language that still wants to be able to make reasonable use of
foreign code written in unsafe languages--a famous source of
annoyance for Rust.

> I hope _nobody_ will have to bother with @live,

It's really hard to see you as only having sincere technical
objections to @live after reading this. Either @live does no
good as you say you think, and enthusiasm for alternatives
to it will persist, or @live will have an effect and this
enthusiasm will wane. I don't think there's a future of "@live
is enthusiastically embraced even though it doesn't help at
all."

> but if they
> will, it will inevitably infect libraries and suddenly, yes, I
> will have to deal with it.

How will you have to deal with it? Code can't require that
their callers have @live. It's your preferred alternative that
would necessarily entangle users of libraries.