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