www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1021--Argument Ownership and Function Calls--Final Review

reply Mike Parker <aldacron gmail.com> writes:
DIP 1021, "Argument Ownership and Function Calls", is now ready 
for Final Review. This is the last chance for community feedback 
before the DIP is handed off to Walter (the author in this case) 
and Átila for the Formal Assessment.

Anyone intending to post feedback in this thread is expected to 
be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md

In it you'll find a link to and summary of the previous review 
round. This round of review will continue until 11:59 pm ET on 
September 30 unless I call it off before then.

Thanks in advance for your participation.
Sep 16 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 16 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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.
Sincere question: do you want people to experiment with it? If so, in what way? People have already come up with holes in your proposal, and you've essentially said that you didn't mind them; so what would people confirming that these holes still exist in the preview implementation change?
Sep 16 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2019 9:47 AM, Olivier FAURE wrote:
 Sincere question: do you want people to experiment with it? If so, in what
way? 
 People have already come up with holes in your proposal, and you've
essentially 
 said that you didn't mind them; so what would people confirming that these
holes 
 still exist in the preview implementation change?
It's not a complete solution. That'll be for the live proposal. But it does solve the more immediate problem of unsafety with refcounted objects.
Sep 18 2019
next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Wednesday, 18 September 2019 at 07:38:49 UTC, Walter Bright 
wrote:
 It's not a complete solution. That'll be for the  live 
 proposal. But it does solve the more immediate problem of 
 unsafety with refcounted objects.
No it doesn't. We've been over this, we've posted about 4 or 5 examples of ways refcounting safety could be broken in the previous thread, Exil already posted two examples in this thread. So I'm going to ask again: why do you ask people to experiment with it if you're going to ignore the holes they find?
Sep 18 2019
prev sibling parent Exil <Exil gmall.com> writes:
On Wednesday, 18 September 2019 at 07:38:49 UTC, Walter Bright 
wrote:
 On 9/16/2019 9:47 AM, Olivier FAURE wrote:
 Sincere question: do you want people to experiment with it? If 
 so, in what way? People have already come up with holes in 
 your proposal, and you've essentially said that you didn't 
 mind them; so what would people confirming that these holes 
 still exist in the preview implementation change?
It's not a complete solution. That'll be for the live proposal. But it does solve the more immediate problem of unsafety with refcounted objects.
Now the DIP makes sense, as to why it doesn't make sense. Because it's not complete. It solves no problem because of this, as someone else has showed. You can't review something that isn't complete as the author will just argue that any problems will be "fixed" in the future. There's nothing more to say... Yew haw cowboy!
Sep 18 2019
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Which IRC it been implemented couple of days ago. Not very much time to kick the tires so to speak. - Alex
Sep 16 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2019 11:59 AM, 12345swordy wrote:
 Which IRC it been implemented couple of days ago. Not very much time to kick
the 
 tires so to speak.
The PR has been around for a month. It was pulled a couple days ago.
Sep 18 2019
prev sibling parent reply IGotD- <nise nise.com> writes:
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. Can it be switched on/off by a compiler switch like now, in order to make existing code pass instead of adding system or trusted? If an ownership problem is encountered, what is the action, compiler warning or error?
Sep 18 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
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".
Sep 19 2019
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md
As Andrei said at DConf 2019, a DIP must be thorough enough such that it should be able to be correctly implemented by a vengeful ex. Currently, the description does not pass this test:
 Therefore, if more than one reference to the same data is 
 passed to a function, they must all be const
``` void foo(scope int[] x, scope int[] y); void main() { int[2] a = [100, 200]; int[2] b = [100, 200]; foo(a[], b[]); // not allowed in vengeful implementation! // The same data is passed, so parameters x and y must be const } ``` ``` void foo(scope immutable int[] x, scope immutable int[] y); void main() { immutable int[4] a; foo(a[], a[]); // not allowed in vengeful implementation! // parameters are immutable, not const } ``` You might say "it is obvious what I meant" but that reasoning didn't prevent DIP1016 [1] (Manu's ref T accepts r-values) from being rejected.
 This builds on the foundation established and tested by DIP 25 
 and DIP 1000
This doesn't help defining "the same data" either, DIP 1000 is superseded and there is little to no specification on how `scope` currently works with the -dip1000 flag. [1] https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
Sep 16 2019
prev sibling next sibling parent reply a11e99z <black80 bk.ru> writes:
On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 DIP 1021, "Argument Ownership and Function Calls", is now ready 
 for Final Review. This is the last chance for community 
 feedback before the DIP is handed off to Walter (the author in 
 this case) and Átila for the Formal Assessment.
does help this DIP with next situation or another option already exists in D? https://run.dlang.io/is/LQJ79M dmd -dip1000 .... --------------------------- import std; struct Data { private void[10] buf; private void* ptr; // some data //TODO. OT // should it be possible to initialize pointers to internals in the default constructor for structs? does DIP-xxxx(idr) solve it? whether its necessary? // this() { ptr = buf.ptr; } // I want that data can be used only at block { that requested it } void[] data() trusted return scope { return ptr[0..10]; // returns some internals } } // user func that work with Data internals that shouldn't run away // user can forget to use "scope" void[] userFunc( ref Data d ) safe { auto tmp = d.data; // FIXME // tmp shouldn't run away. // "scope" in user hands is not solution. (scope ref Data d) // lib should control access to lib internals not the user. return tmp; } void main() { Data d; userFunc( d ); "data runs away. and dip1000 is enabled.".writeln; }
Sep 16 2019
parent a11e99z <black80 bk.ru> writes:
On Monday, 16 September 2019 at 10:46:41 UTC, a11e99z wrote:
 On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 DIP 1021, "Argument Ownership and Function Calls", is now 
 ready for Final Review. This is the last chance for community 
 feedback before the DIP is handed off to Walter (the author in 
 this case) and Átila for the Formal Assessment.
does help this DIP with next situation or another option already exists in D? https://run.dlang.io/is/LQJ79M dmd -dip1000 .... --------------------------- import std;
one more indirection: https://run.dlang.io/is/h1ahew
Sep 16 2019
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 16.09.19 11:13, Mike Parker wrote:
 The current revision of the DIP for this review is located here:
 
 https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9
e46/DIPs/DIP1021.md 
Walter hasn't changed a single thing, so the criticism from the last round still applies. I'll repeat mine (and maybe elaborate on it): The DIP does not show what benefit it brings. In the Rationale section, it presents buggy code. In the Description section, it proposes a language change. But it fails to show how the change would help prevent the bug. In particular, "the checks would only be enforced for safe code", but the bad code in the given example calls `free` which means it can be trusted at best. So it seems like the DIP wouldn't apply to its own motivating example.
Sep 16 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 16 September 2019 at 11:05:21 UTC, ag0aep6g wrote:
 On 16.09.19 11:13, Mike Parker wrote:
 The current revision of the DIP for this review is located 
 here:
 
 https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md
Walter hasn't changed a single thing, so the criticism from the last round still applies. I'll repeat mine (and maybe elaborate on it): The DIP does not show what benefit it brings. In the Rationale section, it presents buggy code. In the Description section, it proposes a language change. But it fails to show how the change would help prevent the bug.
It been shown here in the exiting work section. https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules -Alex
Sep 16 2019
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
 It been shown here in the exiting work section.
 https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules
A link to the documentation of another language is not good enough for a DIP.
Sep 16 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 16 September 2019 at 15:11:07 UTC, ag0aep6g wrote:
 On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
 It been shown here in the exiting work section.
 https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules
A link to the documentation of another language is not good enough for a DIP.
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Sep 16 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 16 September 2019 at 15:33:31 UTC, 12345swordy wrote:
 https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
I'm going to be blunt, moreso than usual: this is a tense discussion about a contentious subject, and right now you're adding nothing of value to it. Yes, DRY is a good principle in software development, in general. It doesn't really apply to a debate process, which doesn't have the same constraints as a body of code or documentation. 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". So I think as a matter of courtesy, you should probably read the arguments that have already been made on the subject before lecturing other people about not repeating things. Sorry, I realize I'm being hostile. But we've been debating this for weeks, and we really don't need another surface level back-and-forth like you're doing.
Sep 16 2019
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 16 September 2019 at 16:34:38 UTC, Olivier FAURE wrote:
 On Monday, 16 September 2019 at 15:33:31 UTC, 12345swordy wrote:
 https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
I'm going to be blunt, moreso than usual: this is a tense discussion about a contentious subject, and right now you're adding nothing of value to it.
You are not a moderator here, so stop acting like one. - Alex
Sep 16 2019
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 16.09.19 18:34, Olivier FAURE wrote:
 On Monday, 16 September 2019 at 15:33:31 UTC, 12345swordy wrote:
 https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
I'm going to be blunt, moreso than usual: this is a tense discussion about a contentious subject, and right now you're adding nothing of value to it. Yes, DRY is a good principle in software development, in general. It doesn't really apply to a debate process, which doesn't have the same constraints as a body of code or documentation. 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". So I think as a matter of courtesy, you should probably read the arguments that have already been made on the subject before lecturing other people about not repeating things. Sorry, I realize I'm being hostile. But we've been debating this for weeks, and we really don't need another surface level back-and-forth like you're doing.
I don't think there's any need to be sorry. Your reaction is appropriate.
Sep 16 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 18 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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
Sep 19 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 19 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright 
wrote:
 D's transitive const has also proved difficult to retrofit into 
 existing code (like the DMD source code).
 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).
I think those two comparisons are interesting, because trusted and const have different semantics, as far incrementally fitting them goes. const (and pure) starts from the "leaves", the small functions that don't call anything else. As your refactoring progresses, more and more functions become pure, closer to the root, until ideally everything but your main() is pure. trusted, on the other hand, is something you're trying to get rid of. You really, really don't want a codebase where half your code is marked as trusted, because that means half your code needs to be audited to find any potential memory vulnerability. The way you've described live, it would be something between the two. Like, it's an attribute you add to functions that you incrementally convert to the new paradigm; but it's also something you really don't want half your code to have, because then you need to manually audit every non- live code interacting with live code to make sure memory corruption doesn't happen. Not sure if I'm explaining this clearly.
 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.
It's 100% memory-safe, transitive, mechanically checkable, malicious-non- trusted-code proof. I've been trying to nail down the semantics, and I think[1] it requires lifetime annotations (I need to take the time to write a demonstration why at some point), but that's nothing that wouldn't apply to the live proposal as well. [1] https://forum.dlang.org/thread/qssaruktegnbtsdjeyri forum.dlang.org
Sep 19 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2019 5:43 AM, Olivier FAURE wrote:
 On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright wrote:
 D's transitive const has also proved difficult to retrofit into existing code 
 (like the DMD source code).
 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).
I think those two comparisons are interesting, because trusted and const have different semantics, as far incrementally fitting them goes. const (and pure) starts from the "leaves", the small functions that don't call anything else. As your refactoring progresses, more and more functions become pure, closer to the root, until ideally everything but your main() is pure. trusted, on the other hand, is something you're trying to get rid of. You really, really don't want a codebase where half your code is marked as trusted, because that means half your code needs to be audited to find any potential memory vulnerability.
I've been looking into making the DMD source code safe. Because of all the interconnected dependencies, it's looking like the only way is to make everything trusted, and then piece by piece make it safe. Because DMD does lazy semantic analysis (for very good reasons), going const has been a frustrating experience and is unlikely to ever happen.
 The way you've described  live, it would be something between the two. Like, 
 it's an attribute you add to functions that you incrementally convert to the
new 
 paradigm; but it's also something you really don't want half your code to
have, 
 because then you need to manually audit every non- live code interacting with 
  live code to make sure memory corruption doesn't happen.
Yes, but code must have a transition path. DMD would still be in C++ if I couldn't translate it function by function, keeping the entire codebase working and passing the test suite at each step. I did a number of ugly things to make it happen - but now that it's in D I gradually go back and fix the compromises. It's like how the first intercontinental railroad was built. It was all quick-and-dirty, slap dash, unsafe, and ramshackle. It was also built entirely with muscle. But once it was done, and trains could be run on it, suddenly it was incredibly useful, money was coming in, etc., and piece by piece the crappy construction was fixed. It could not have been built otherwise.
 Not sure if I'm explaining this clearly.
 
 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.
It's 100% memory-safe, transitive, mechanically checkable, malicious-non- trusted-code proof. I've been trying to nail down the semantics, and I think[1] it requires lifetime annotations (I need to take the time to write a demonstration why at some point), but that's nothing that wouldn't apply to the live proposal as well. [1] https://forum.dlang.org/thread/qssaruktegnbtsdjeyri forum.dlang.org
Is there a language that uses this, or is it entirely new?
Sep 19 2019
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 19 September 2019 at 20:34:47 UTC, Walter Bright 
wrote:
 [snip]
 Is there a language that uses this, or is it entirely new?
I understood it as being a mixture of pony’s reference capabilities and Rust’s borrow checker, but I could be wrong. I don’t think the addition of DIP 1021 precludes the future addition of unique the way I read it. The addition of unique might need to take DIP 1021 into account.
Sep 19 2019
prev sibling parent Exil <Exil gmall.com> writes:
On Thursday, 19 September 2019 at 20:34:47 UTC, Walter Bright 
wrote:
 It's like how the first intercontinental railroad was built. It 
 was all quick-and-dirty, slap dash, unsafe, and ramshackle. It 
 was also built entirely with muscle. But once it was done, and 
 trains could be run on it, suddenly it was incredibly useful, 
 money was coming in, etc., and piece by piece the crappy 
 construction was fixed. It could not have been built otherwise.
Like auto-decoding? A compiler isn't a railroad. You can build your implementation without forcing itself into stable/master. If you need to build it as quickyl and unsafely as you can, one rail at a time and plug the holes as you find them. Fine, that sounds extremely *unstable*. You can do that without integrating it into stable/master.
Sep 19 2019
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright 
wrote:

 [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.
There are two 100% solutions that I am aware of. One is Rust's borrow checker, which I'm assuming is already familar to all, and the other is Pony's reference capabilities [1]. As the ownership and borrowing vision for D is being polished, I think it would be worthwhile to become familiar with Pony's model even if only to provide contrast and solidify existing ideas. Graydon Hoare [2] and Niko Matsakis [3], both rock stars in the Rust community, provided some interesting commentary on Pony's model. [1] - https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html [2] - https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxkmm8/ [3] - https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxvxky/ I'm really excited about where you're going with all of this, but this DIP does seem like an odd thing to do in isolation from a complete ownership/borrowing model. It still seems to me that a complete ownership/borrowing/reference-capabilities solution, in the general case, would already handle the use cases addressed by this DIP. Mike
Sep 19 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2019 6:26 AM, Mike Franklin wrote:
 On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright wrote:
 
 [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.
There are two 100% solutions that I am aware of.  One is Rust's borrow checker, which I'm assuming is already familar to all, and the other is Pony's reference capabilities [1].  As the ownership and borrowing vision for D is being polished, I think it would be worthwhile to become familiar with Pony's model even if only to provide contrast and solidify existing ideas. Graydon Hoare [2] and Niko Matsakis [3], both rock stars in the Rust community, provided some interesting commentary on Pony's model. [1] - https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html [2] - https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_sa e_language/cqxkmm8/ [3] - https://www.reddit.com/r/rust/comments/34rszb/pony_type_and_memory_safe_language/cqxvxky/
Thanks for the references.
 I'm really excited about where you're going with all of this, but this DIP
does 
 seem like an odd thing to do in isolation from a complete ownership/borrowing 
 model.  It still seems to me that a complete 
 ownership/borrowing/reference-capabilities solution, in the general case,
would 
 already handle the use cases addressed by this DIP.
An OB system would build on and extend this DIP, not replace it. It's the next step in: 1. DIP25 built on and extended the existing checks for returning the address of a local. 2. DIP1000 built on and extended DIP15 by adding checking for pointers, not just references. 3. DIP1021 built on and extended DIP1000 by adding the notion of OB for function parameters. Look at the implementation of DIP1021 - it is most definitely leveraging the code for 1 and 2. A full OB system will leverage the code added for 3, too. DIP1021 also has the advantage of trying out OB on a limited scale, and gently introducing D users to the concepts behind it. Code modified to work with DIP25, DIP1000, and DIP1021 will not need a do-over for OB, it'll just be further down the same road. As you're well aware, upgrading Phobos to DIP1000 was a bit of a struggle, but I hope you'll agree it was well worth it. I suspect that going from pre-DIP25 to OB in one step would be too wrenching of a change.
Sep 19 2019
prev sibling parent reply Exil <Exil gmall.com> writes:
On Monday, 16 September 2019 at 14:45:49 UTC, 12345swordy wrote:
 On Monday, 16 September 2019 at 11:05:21 UTC, ag0aep6g wrote:
 On 16.09.19 11:13, Mike Parker wrote:
 The current revision of the DIP for this review is located 
 here:
 
 https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md
Walter hasn't changed a single thing, so the criticism from the last round still applies. I'll repeat mine (and maybe elaborate on it): The DIP does not show what benefit it brings. In the Rationale section, it presents buggy code. In the Description section, it proposes a language change. But it fails to show how the change would help prevent the bug.
It been shown here in the exiting work section. https://doc.rust-lang.org/1.8.0/book/references-and-borrowing.html#the-rules -Alex
Rust's implementation is much more complex than what is going to be capable of being implemented in D. So unless you're proposing creating the exact same feature with the exact same rules then that reference means nothing. What I find funny is that the DIP didn't change at all. I hear "write a DIP" all the time whenever something comes up. This DIP is so barebones, I expect Walter to hold himself to same standard as he holds others to. I don't know why this is even going through the DIP process. It's obviously going to be added even if the DIP was an empty page. This solves a problem that is already solved by using a GC. The only example provided by the DIP still works (though you do have to make malloc/free trusted). So the only real use case I can see of this is to prevent use-after-free bugs, but you can't even do that cause you can't use malloc/free in safe. Even if you could, the current implementation doesn't stop it from being freed. After using it for a little bit, the section on breaking changes should definitely be expanded. "Unknown how prevalent this pattern is". I feel this will break a lot of code. Using system/ trusted isn't a real solution if someone is actually using safe. Especially when you consider cases like foreach(): Currently seems to be a bug, doesn't take into consideration arrays inside foreach loops. But considering that you can't do it outside a loop, you probably shouldn't be able to do it inside the loop either. safe: void foo(ref int, ref int) { } void test() { int[5] arr; // foo(arr[0], arr[0]); // error here foreach(size_t i, ref int a; arr) { foo(a, arr[i]); // but ok here } }
Sep 17 2019
next sibling parent reply Exil <Exil gmall.com> writes:
Another issue:

      safe:


     void foo(ref int, ref int) {
     }

     void test() {
         int b;

         int* a = &b;
         int* c = &b;

         // foo( b, b); // error

         foo( *a, *c); // but this is ok
     }
Sep 17 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/17/2019 10:18 AM, Exil wrote:
 Another issue:
 
       safe:
 
 
      void foo(ref int, ref int) {
      }
 
      void test() {
          int b;
 
          int* a = &b;
          int* c = &b;
 
          // foo( b, b); // error
 
          foo( *a, *c); // but this is ok
      }
Yeah, that requires data flow analysis, which this DIP doesn't do. The live one covers flow analysis.
Sep 18 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/17/2019 8:54 AM, Exil wrote:
       safe:
 
      void foo(ref int, ref int) {
      }
 
      void test() {
          int[5] arr;
 
          // foo(arr[0], arr[0]); // error here
 
          foreach(size_t i, ref int a; arr) {
              foo(a, arr[i]); // but ok here
          }
      }
That's a problem with the implementation, not the DIP.
Sep 18 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2019 2:50 AM, Walter Bright wrote:
 That's a problem with the implementation, not the DIP.
I take that back, it's a data flow analysis issue. The DIP does not cover data flow analysis.
Sep 18 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 18 September 2019 at 11:14:01 UTC, Walter Bright 
wrote:
 On 9/18/2019 2:50 AM, Walter Bright wrote:
 That's a problem with the implementation, not the DIP.
I take that back, it's a data flow analysis issue. The DIP does not cover data flow analysis.
Which I am assuming you be creating a DIP that tackle the data flow analysis issue in the future right? - Alex
Sep 18 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 18 2019
parent Max Haughton <maxhaton gmail.com> writes:
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)
Sep 18 2019
prev sibling next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 DIP 1021, "Argument Ownership and Function Calls", is now ready 
 for Final Review. This is the last chance for community 
 feedback before the DIP is handed off to Walter (the author in 
 this case) and Átila for the Formal Assessment.
I don't understand the point of this review thread. I know I've been hostile to this proposal, but beyond the object-level problems (which I won't repeat), there seems to be a problem of process here. Reviewers have given feedback. Walter has, as you yourself noted, declared that feedback was invalid and already covered by the existing proposal; as such, the proposal is being posted again with no content change. Like, I get that it isn't your job to agree or disagree with Walter on an object level; but on a process level, something clearly isn't working, and it feels like you should intervene. Either by putting your foot down and asking Walter make changes (like, any changes at all); by having some sort of mediator role between Walter and reviewers, maybe by organizing a chat or something; or by fast-tracking the proposal all the way and skipping the final review. Because right now, I have to agree with Exil from last thread: I'm saying this with all the respect I have for you, but this is a charade. You're asking for feedback that we know for a fact Walter will ignore, because he has ignored all feedback given so far.
Sep 16 2019
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 16 September 2019 at 16:51:41 UTC, Olivier FAURE wrote:

 I don't understand the point of this review thread.

 I know I've been hostile to this proposal, but beyond the 
 object-level problems (which I won't repeat), there seems to be 
 a problem of process here.

 Reviewers have given feedback. Walter has, as you yourself 
 noted, declared that feedback was invalid and already covered 
 by the existing proposal; as such, the proposal is being posted 
 again with no content change.

 Like, I get that it isn't your job to agree or disagree with 
 Walter on an object level; but on a process level, something 
 clearly isn't working, and it feels like you should intervene. 
 Either by putting your foot down and asking Walter make changes 
 (like, any changes at all); by having some sort of mediator 
 role between Walter and reviewers, maybe by organizing a chat 
 or something; or by fast-tracking the proposal all the way and 
 skipping the final review.

 Because right now, I have to agree with Exil from last thread: 
 I'm saying this with all the respect I have for you, but this 
 is a charade. You're asking for feedback that we know for a 
 fact Walter will ignore, because he has ignored all feedback 
 given so far.
It is not my place, with any DIP, to "put my foot down". The process does not require any revisions between review rounds. It is 100% up to the author to accept or reject feedback. Most of the DIPs that have gone through the process change very little between Community Review and Final Review. The purpose of the Final Review is to provide one final chance for any major points of feedback that might have been missed in the previous review rounds. Again, it is up to the author, not me, to determine if the feedback is valid and whether or not to proceed. I'm a shepherd, not a gatekeeper. If you'd like to have a discussion about the DIP process, please start a new thread. This one is not the place for it. Thanks!
Sep 16 2019
prev sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
  DIP 1021, "Argument Ownership and Function Calls", is now ready
 On Monday, 16 September 2019 at 09:13:48 UTC, Mike Parker wrote:
 DIP 1021, "Argument Ownership and Function Calls", is now ready 
 for Final Review. This is the last chance for community 
 feedback before the DIP is handed off to Walter (the author in 
 this case) and Átila for the Formal Assessment.

 Anyone intending to post feedback in this thread is expected to 
 be familiar with the reviewer guidelines:

 https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

 The current revision of the DIP for this review is located here:

 https://github.com/dlang/DIPs/blob/1d78cdf1613911439848a49e9053a7bbf5a9de46/DIPs/DIP1021.md
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. TBH, it's not at all clear to me that even Walter knows what the end result will be. Maybe he's just making it up as he goes along? Without understanding the whole thing there is not much to discuss. Maybe it's a good idea, maybe not. Who knows. Anyway, my opinion is all this stuff designed to support nogc turn D into a mess. Why not just use Rust instead?
Sep 16 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 18 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Wednesday, 18 September 2019 at 11:18:30 UTC, Walter Bright 
wrote:
 The smaller picture is that one cannot create a ref counted 
 objected that can safely expose a ref to its payload without 
 this proposal.
One cannot create a ref-counted object that can safely expose its payload *with* this proposal either. eg: safe: void foo(ref RefCounted rc, ref RefCounted rc2) { rc.reset(); rc2.get() = 42; // Whoops, memory corruption } void test() { RefCounted rc = someData(); RefCounted* rc2 = &rc; foo( rc, *rc2 ); } Any proposal which doesn't have data flow analysis won't provide actual memory safety.
Sep 18 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 18 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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.
Sep 19 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Sep 19 2019
next sibling parent Olivier FAURE <couteaubleu gmail.com> writes:
On Thursday, 19 September 2019 at 10:17:43 UTC, Walter Bright 
wrote:
 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 bit of friendly advice: if you don't want people to berate you, don't spend months ignoring things they're trying to communicate to you, especially when they are putting significantly more visible effort analyzing your points than you put into writing them. Seriously, I don't care. I've spent months trying to communicate the flaws of your proposal to you. I did it with as much politeness and respect as someone can have while criticizing someone else's plans. I wrote examples, counter-examples, tried to understand your general goal, tried to formulate my points as clearly as I could, wrote a beginning of a counter-proposal (which I talked to you about, this isn't anything new), etc. I'm pretty sure I have put more effort into communicating with you than any contributor on this forum for the last two years. You've ignored or dismissed everything I said. So, I don't want to be hostile, I don't want to be rude, and I try to say this with stoicism. But I maintain what I said earlier: you make it really, *really* difficult and painful to communicate with you. From what I've seen and hear from D contributors, I'm not isolated in that sentiment.
Sep 19 2019
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 19.09.19 12:17, Walter Bright wrote:
 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".
 ...
Your own answer to this was "we plug the holes one by one". Do you see the double standard? Anyway, I have actually done this but you just ignored the explanation and went back to claiming that my suggestions do not meet this requirement. I simply can't spend tens of hours in debates every week anymore.
 2. pointing to an existing implementation in another language that 
 proves point (1) would be very helpful.
 ...
You are pointing to Rust, but you are not doing what Rust does. And anyway, Rust does not support GC. Do you really want to remove GC from D?
 ...
 
 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!
The issue is that you make it seem like you are unable to recognize valid criticism, let alone better (i.e., non-terrible) proposals. I don't really have time to create a polished DIP and I'm not even sure you would acknowledge it as such. All I can say is that I'll severely regret my investment in D if live moves forward. This is not at all where I expected the language to go. Where is the pragmatism?
Sep 19 2019
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 20.09.19 03:17, Timon Gehr wrote:
 
 
 P.S. I've encouraged people for the last 10 years to submit proposals on 
 how to make D memory safe.
BTW: The problem is not that D is not memory safe. The "problem" is that D relies on GC to be memory safe. There may be some trusted code that uses manual memory management and violates safe D memory safety, but that is not the fault of the language specification. To solve the problem you need to give more tools to this currently broken trusted code so it can restrict safe code suitably in it's usage patterns, not destroy GC and all the actually safe code that has been written so far.
Sep 19 2019
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 20.09.19 03:41, Timon Gehr wrote:
 in it's usage patterns
its. its usage patterns...
Sep 19 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2019 6:17 PM, Timon Gehr wrote:
 Anyway, I have actually done this but you just ignored the 
 explanation and went back to claiming that my suggestions do not meet this 
 requirement.
If you can link to your proposal, polished or not, that would be helpful.
Sep 19 2019
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 20.09.19 05:10, Walter Bright wrote:
 On 9/19/2019 6:17 PM, Timon Gehr wrote:
 Anyway, I have actually done this but you just ignored the explanation 
 and went back to claiming that my suggestions do not meet this 
 requirement.
If you can link to your proposal, polished or not, that would be helpful.
It was in private emails. I'll try to create a self-contained write-up for general consumption next week, I have a paper deadline on Wednesday.
Sep 20 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2019 5:17 AM, Timon Gehr wrote:
 It was in private emails. I'll try to create a self-contained write-up for 
 general consumption next week, I have a paper deadline on Wednesday.
Thank you, that'll be good! Post it here when ready.
Sep 20 2019
prev sibling parent reply Piotrek <dummy dummy.gov> writes:
On Thursday, 19 September 2019 at 10:17:43 UTC, Walter Bright 
wrote:
 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.
Sorry to say that but Rust community is full of extremists. The promises of the Rust language has to taken with grain of salt. I've seen many negative opinions about the actual Rust usage. Let me list just 3 points of the Rust language issues on software development(in general): 1. No garbage collector - this means no fully automatic memory management (cycles). 2. Despite the Rust funboys' claims a compiler won't fix all memory bugs at compile time, just to name array accesses, but that is not all. 3. No GUI library because of the language limitations. Of course any memory safety checks at compile time are nice but I would be careful with paying too much for it. Because of its design Rust seems to be less productive than other popular languages . Cheers, Piotrek
Sep 20 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/20/2019 9:46 AM, Piotrek wrote:
 Sorry to say that but Rust community is full of extremists. The promises of
the 
 Rust language has to taken with grain of salt. I've seen many negative
opinions 
 about the actual Rust usage.
 
 Let me list just 3 points of the Rust language issues on software
development(in 
 general):
 
 1. No garbage collector - this means no fully automatic memory management
(cycles).
 2. Despite the Rust funboys' claims a compiler won't fix all memory bugs at 
 compile time, just to name array accesses, but that is not all.
 3. No GUI library because of the language limitations.
 
 Of course any memory safety checks at compile time are nice but I would be 
 careful with paying too much for it.
 
 Because of its design Rust seems to be less productive than other popular 
 languages .
I agree that Rust appears to be significantly harder to write code in. I do not know why GUI libraries appear to be a big problem for Rust. But consider also that functional programming has its problems as well, both in terms of expressivity and performance. D supports FP as a useful paradigm, not as a religion. It allows one to easily mix&match FP with imperative code. I figure we can do the same for ownership/borrowing, that's why it has a separate function attribute ( live) for it.
Sep 20 2019
next sibling parent Piotrek <dummy dummy.gov> writes:
On Friday, 20 September 2019 at 21:51:17 UTC, Walter Bright wrote:
 D supports FP as a useful paradigm, not as a religion. It 
 allows one to easily mix&match FP with imperative code.

 I figure we can do the same for ownership/borrowing, that's why 
 it has a separate function attribute ( live) for it.
Personally I am supporter of this approach and I think it is very comfortable for an average software developer. My observation as a programmer is that in general easier solutions win. This is a simplification of course because there are other critical factors like tools, libraries, compatibility, cost etc. For example I can watch Python victory march in the IT industry. It devastates other languages in terms of adoption. Yet it is slow, has garbage collector and other "features" which are considered not nice by the programming elite. But on the other hand it has almost all functionalities you would think of and they work quite well with each other. Just search for a library, import a module and call a function. Easy, elegant and effective. And I think it is good to look at "academic solutions" like borrow checker from a proper perspective as they usually don't work seamlessly in large projects and can cost more than they give. Cheers, Piotrek
Sep 21 2019
prev sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Friday, 20 September 2019 at 21:51:17 UTC, Walter Bright wrote:
 D supports FP as a useful paradigm, not as a religion. It 
 allows one to easily mix&match FP with imperative code.

 I figure we can do the same for ownership/borrowing, that's why 
 it has a separate function attribute ( live) for it.
That really depends on what you mean by "mix-and-match". If you mean as a transition path, where you try to eliminate most of the non- live code as fast as you can, then yes. If you mean, like with const, some parts of the code use it, some parts don't, but the latter can call the former while remaining safe, then no. Given live as you described it, non- live functions calling live functions would have to be system or trusted, which isn't a state you want half your codebase to be in. eg: safe live SmartPtr!int createPtr() { return SmartPtr!int(); } safe live void removePtr(ref SmartPtr!int ptr) { ptr.reset(); } safe int* identity(return ref int n) { return &n; } safe void test() { auto ptr = createPtr; int* p = identity(ptr.get()); removePtr(ptr); *p = 1; // Memory corruption }
Sep 23 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/23/2019 1:34 AM, Olivier FAURE wrote:
 Given  live as you described it, non- live functions calling  live functions 
 would have to be  system or  trusted, which isn't a state you want half your 
 codebase to be in.
live rules only apply to the internals of the live function. At some point there must be a presumption that functions that call the live function or the functions the live function calls conform at least to the live function interface. Otherwise there is simply no way to incrementally adopt live.
Sep 23 2019
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Monday, 23 September 2019 at 22:13:11 UTC, Walter Bright wrote:
 Otherwise there is simply no way to incrementally adopt  live.
Yes, that's the problem.
  live rules only apply to the internals of the  live function. 
 At some point there must be a presumption that functions that 
 call the  live function or the functions the  live function 
 calls conform at least to the  live function interface.
The problem is, since the compiler can't check that non- live functions conform to the live invariants, it has to trust the developer, which severely weakens safe (if nothing else, because it makes it possible for someone to do a memory corruption in a codebase with no system or trusted functions).
Sep 24 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2019 1:30 AM, Olivier FAURE wrote:
 The problem is, since the compiler can't check that non- live functions
conform 
 to the  live invariants, it has to trust the developer, which severely weakens 
  safe (if nothing else, because it makes it possible for someone to do a
memory 
 corruption in a codebase with no  system or  trusted functions).
It wouldn't be any less safe than it is now. Remember, live adds a layer of more checking, not less.
Sep 24 2019
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 23 September 2019 at 22:13:11 UTC, Walter Bright wrote:
 On 9/23/2019 1:34 AM, Olivier FAURE wrote:
 Given  live as you described it, non- live functions calling 
  live functions would have to be  system or  trusted, which 
 isn't a state you want half your codebase to be in.
live rules only apply to the internals of the live function. At some point there must be a presumption that functions that call the live function or the functions the live function calls conform at least to the live function interface. Otherwise there is simply no way to incrementally adopt live.
The safe by default dip is part of the plan of adopting live? -Alex
Sep 24 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/24/2019 12:50 PM, 12345swordy wrote:
 The  safe by default dip is part of the plan of adopting  live?
No.
Sep 24 2019
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.09.19 11:09, Olivier FAURE wrote:
 
 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.
I'd be happy and excited if that was the extent of the problems! live is not the Rust model! Rust does not have a language built-in notion of unique pointer, and it is not necessary (nor sufficient) to have it if your borrowing works. Mixing up GC pointers and unique pointers is a terrible idea. Why is live trying to _remove_ GC from D?
Sep 19 2019
prev sibling parent Exil <Exil gmall.com> writes:
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.
Lol, this sounds like a sinking ship. I like your reference.
Sep 19 2019
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Sep 18 2019