Is borrow checker the right thing for D?

[Timon Gehr]

On 17.08.19 14:36, victoroak wrote:
> On Saturday, 17 August 2019 at 12:09:19 UTC, Timon Gehr wrote:
>>
>> [...]
>>
>> 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.
> 
> As someone who likes Rust,

Rust is a fine language.

> I like the idea of having just one mutable 
> reference to a strict. I'm no language designer but it makes sense to 
> try to borrow a model that already works in another language.

Not without understanding what it does and why it works, and what 
features it may not be (easily) compatible with.

https://en.wikipedia.org/wiki/Cargo_cult

E.g., this "plane" will not fly:
http://erwin.bernhardt.net.nz/oceania/images/vanuatutannacargocult02.jpg

It superficially looks like a plane, but it does not actually have the 
same function.

> I do think 
> that Rust has a lot more than just one mutable reference that 
> contributes to the safety and maybe it does not makes sense for D to do 
> that.
> ...

If any of the proposals would in fact guarantee that at any time there 
was either one mutable access path or an arbitrary amount of non-mutable 
access paths to each value, I wouldn't call them a cargo cult. But that 
still wouldn't necessarily make sense, because @safe D code can access 
raw pointers, while safe Rust code can't. (This is because D has a 
built-in garbage collector. In Rust, GC is not entirely trivial to make 
safe, useful and efficient at the same time, and they haven't settled on 
a solution.)

> The problem is that I can't think any way besides returning a refcounted 
> pointer in opIndex to make a safe Vector that has a reserve method or a 
> insert that reallocate.
> ...

As I said, there is no actual proposal in the pipeline that allows 
making a safe vector of the kind that Rust has, even though there are 
proposals that superficially make the D type system look more similar to 
Rust's to a casual observer. I keep pointing it out but so far this has 
not been acknowledged as a fatal flaw of those proposals.

> If you have a better way that does not involve copying Rust

(To get a _copy_ of Rust, download rustc. Anything else requires some 
language design expertise.)

I don't understand why you think I think using Rust for inspiration is a 
bad thing. I'm not opposed to doing what Rust does. Rust _actually does 
some version of what I suggested in my last post_. The problem is that 
it seems that very few people actively participating on this forum 
actually understand what it is that Rust does. (E.g., a very common 
misconception is that Rust unsafe is like D @system. Rust unsafe is 
actually like D @trusted. Another misconception is that Rust ensures 
that raw mutable pointers don't alias.)

> I think you could let us know.
We first need to agree on what the actual problem is before discussing 
solutions. And once we do, I don't care whether we (actually!) do what 
Rust does or whether we instead settle for fractional permissions 
implemented in a super-general dependently-typed typestate system. The 
only thing that's important to me is that the solution works and doesn't 
have obvious design flaws. There are existing proposals being considered 
that fail those criteria, and that just shouldn't happen. Pointing that 
out is a meaningful contribution, but it takes away some of my spare 
time from more useful contributions such as participating in a working 
group that designs solutions that actually work. However, such more 
useful endeavors can't be fruitful (and I'm not betting my precious 
spare time on them) unless decision makers actually acquire _some_ 
expertise on this subject matter.