On Wednesday, 18 September 2019 at 11:18:30 UTC, Walter Bright wrote:
> On 9/16/2019 11:23 AM, nkm1 wrote:
>> The problem with this DIP is it a part of some bigger picture (which includes DIP1000, DIP25 and probably other stuff) and it seems no one understands what this bigger picture is.
>
> The bigger picture is:
>
> https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
>
> The smaller picture is that one cannot create a ref counted objected that can safely expose a ref to its payload without this proposal.

I, for one, like this DIP. Mostly because it signals me where Walter wants to take D, and I like the direction.

On 9/18/2019 5:15 AM, Olivier FAURE wrote:
> Any proposal which doesn't have data flow analysis won't provide actual memory safety.

We plug the holes one by one.

On 9/16/2019 9:34 AM, Olivier FAURE wrote:
> More importantly, I've already gone on at length about why Rust isn't directly comparable to D, and why this proposal in particular is very different from Rust's memory model, and as such needs a deeper analysis than "we'll do it like Rust".

The point that matters here is the idea of having only one mutable pointer to a memory object at a time, or having many const pointers to a memory object. But not both.

The details of how one achieves that can vary from language to language, but I believe as long as that principle is followed, it will be sound.

On 9/18/2019 6:03 AM, 12345swordy wrote:
> Which I am assuming you be creating a DIP that tackle the data flow analysis issue in the future right?

That's the plan. I even wrote an article about it on the D blog.

On Thursday, 19 September 2019 at 04:41:50 UTC, Walter Bright wrote:
> On 9/18/2019 6:03 AM, 12345swordy wrote:
>> Which I am assuming you be creating a DIP that tackle the data flow analysis issue in the future right?
>
> That's the plan. I even wrote an article about it on the D blog.

Is the plan for @live - or whatever it gets called, dip2000? - to be one big dip or incremental chunks over time?

Also, at AST level or something lower? (Although I imagine it's feasible at AST level I can't help but see it being difficult to abstract, assuming it plays in the same pit as the rest of the sema)

On 9/18/2019 1:42 AM, IGotD- wrote:
> On Monday, 16 September 2019 at 10:06:55 UTC, Walter Bright wrote:
>> DIP 1021 can be experimented with as the code is now in the compiler and enabled with -preview=useDIP1021. I'd expect some trouble with it as it doesn't have much wear on the tires.
> 
> A few questions:
> 
> What would the default behaviour of the compiler be, is the ownership check on or off.

-preview switches mean "opt-in".

On Thursday, 19 September 2019 at 02:59:22 UTC, Walter Bright wrote:
> On 9/16/2019 9:34 AM, Olivier FAURE wrote:
>> More importantly, I've already gone on at length about why Rust isn't directly comparable to D, and why this proposal in particular is very different from Rust's memory model, and as such needs a deeper analysis than "we'll do it like Rust".
>
> The point that matters here is the idea of having only one mutable pointer to a memory object at a time, or having many const pointers to a memory object. But not both.
>
> The details of how one achieves that can vary from language to language, but I believe as long as that principle is followed, it will be sound.

Leaving aside my other gripes with this DIP, I think that broader vision is debatable.

It's how Rust does it, but I would argue [1] that the Rust model is way too restrictive. Its cuts off a lot of designs that are provably safe, and it basically forces you to rework your design from the ground up, which is kind of a problem for a language with existing codebases.

Your solution to that problem is to have a @live function, with the idea that users can upgrade their code incrementally and avoid a complete refactor. I'm extremely skeptical that idea can work, because @live functions will make assumptions about the pointer graph passed to them (no duplicate mutable pointers) that non-@live functions calling them won't be obligated to uphold. So calling a @live function from a non-@live function won't be safe.

[1] https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088

On Thursday, 19 September 2019 at 02:54:57 UTC, Walter Bright wrote:
> On 9/18/2019 5:15 AM, Olivier FAURE wrote:
>> Any proposal which doesn't have data flow analysis won't provide actual memory safety.
>
> We plug the holes one by one.

So you're essentially saying "I have a broad solution in mind. I have a general idea of how the broad solution will work, but I want to implement the most actionable part before making more elaborate plans."

The problems with that approach are:
- You're holding yourself to a way, way lower standard than you hold other contributors.
- The "most actionable part" isn't very actionable at all given it brings no additional memory safety whatsoever.
- You're committing to the broad solution prematurely.

I'm going to focus on point 3, because my understanding is that you consider points 1 and 2 invalid.

You're explicitly assuming that "one mutable pointers or several const pointers" is the only possible model for GC-less memory safety, and as such you're utterly refusing to engage in any discussion of the potential downsides and drawbacks of such an approach.

You're basically saying "It doesn't matter if implementing the Rust model in D creates problems. We need to implement that model, nothing else matters."

And so you're working to implement this half-baked "can't pass the same argument twice" change, even though it brings no additional memory safety, and probably won't really reduce the work of implementing full lifetime semantics much.

My point, from the beginning, has always been this:

You're skipping steps.

No, Rust isn't the only possible model for memory safety. Reference-counting isn't the only possible memory-safe data structure. The "foobar(rcObject, &rcObject.data)" problem that has been floated around for a few years isn't the only challenge to implementing a safe GC-less model.

The reason I'm strongly opposed to this DIP, is that it should be based on a thorough analysis of possible memory safety models, advantages of different models over each other, and what model would be most suitable for D and why.

Instead, it acts like the analysis was already done and everybody agreed the Rust model was the best and all that's left is implementation details.

On 9/19/2019 1:31 AM, Olivier FAURE wrote:
> It's how Rust does it, but I would argue [1] that the Rust model is way too restrictive. Its cuts off a lot of designs that are provably safe, and it basically forces you to rework your design from the ground up, which is kind of a problem for a language with existing codebases.

That's true. Functional programming has the same problem. But we find it advantageous to support FP when people want to use FP.

D's transitive const has also proved difficult to retrofit into existing code (like the DMD source code).


> Your solution to that problem is to have a @live function, with the idea that users can upgrade their code incrementally and avoid a complete refactor. I'm extremely skeptical that idea can work, because @live functions will make assumptions about the pointer graph passed to them (no duplicate mutable pointers) that non-@live functions calling them won't be obligated to uphold. So calling a @live function from a non-@live function won't be safe.

That's right, it won't be. Just like if you call an @trusted function from an @safe one, it won't be safe, either (at least the compiler can't check it for you).


> [1] https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088

I haven't studied that. Is it a 100% 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.

A bit of friendly advice - berating me is not a great way to sell me on your ideas. My natural reaction to that is to look hard for ways to reject it. If your idea really is better, then you lose, I lose, and the D community loses.

A much better method is to start by:

1. explaining that your method meets the requirement of 100% mechanically checkable memory safety, that it's not just a collection of "best practices".

2. pointing to an existing implementation in another language that proves point (1) would be very helpful.

3. explaining why it is better than the ownership/borrowing model.

Note that Rust has user base of 50,000. There's pretty strong evidence that it works. I haven't seen any articles or ripostes showing that it doesn't work.

That's what any competing proposal simply has to compare itself to. Not just me, but anyone else who is interested in using D for 100% memory safe code.

---

P.S. I've encouraged people for the last 10 years to submit proposals on how to make D memory safe. Nothing happened but a few hand-wavy suggestions. I gave up waiting, now I'm moving forward one way or another. If that's what it takes to get people motivated to come up with better proposals, that's good!