www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP 1021--Argument Ownership and Function Calls--Formal Assessment

reply Mike Parker <aldacron gmail.com> writes:
DIP 1021, "Argument Ownership and Function Calls", has been 
formally accepted with minor revision. It was updated to make 
clear that the proposal is one piece of a bigger plan.

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
Oct 20 2019
next sibling parent reply Exil <Exil gmall.com> writes:
  This proposal is one step toward a larger goal outlined in the 
 blog post ['Ownership and Borrowing in 
 D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/).


That's the only line that was added, no other changes were made 
to the core DIP from the first revision to the last. Big ducking 
surprise this got accepted anyways.
Oct 21 2019
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 21, 2019 6:59:21 AM MDT Exil via Digitalmars-d-announce 
wrote:

  This proposal is one step toward a larger goal outlined in the

 blog post ['Ownership and Borrowing in
 D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/).


 That's the only line that was added, no other changes were made
 to the core DIP from the first revision to the last. Big ducking
 surprise this got accepted anyways.


Did you expect anything else? Given that it was Walter's DIP, and he's
making the decisions, the only way that the DIP was going to change was if
he were convinced that the DIP was flawed. He's been convinced of that
before (e.g. the DIP that was for adding a bottom type was written by
Walter, but it was rejected, because the community convinced him that it was
a bad idea). He just wasn't convinced that this DIP was a bad idea.

Personally, I didn't see any problem with this DIP, since it just tightened
down  safe a bit. Whether the next steps in the "larger goal" are good ones
is another matter entirely, and those will be put in a DIP (or multiple
DIPs) and argued on their own at some point. And if they're bad ideas, then
hopefully he will be convinced of that when those DIPs are discussed.
Ultimately though, no matter who comes up with the DIP, Walter has to be
convinced that it's a good idea. It's just that if it's his DIP, he's
already convinced that it's a good idea, so someone has to then convince him
otherwise for it to not be accepted.

Fortunately, while Walter certainly doesn't have a perfect track record, he
has a pretty darn good one, or D wouldn't be what it is today.

- Jonathan M Davis
Oct 22 2019
parent reply Exil <Exil gmall.com> writes:
On Wednesday, 23 October 2019 at 00:03:35 UTC, Jonathan M Davis 
wrote:

 On Monday, October 21, 2019 6:59:21 AM MDT Exil via 
 Digitalmars-d-announce wrote:

  This proposal is one step toward a larger goal outlined in 
 the

 blog post ['Ownership and Borrowing in 
 D'](https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/).


 That's the only line that was added, no other changes were 
 made to the core DIP from the first revision to the last. Big 
 ducking surprise this got accepted anyways.


 Did you expect anything else? Given that it was Walter's DIP, 
 and he's making the decisions, the only way that the DIP was 
 going to change was if he were convinced that the DIP was 
 flawed. He's been convinced of that before (e.g. the DIP that 
 was for adding a bottom type was written by Walter, but it was 
 rejected, because the community convinced him that it was a bad 
 idea).


I wasn't expecting any better, but I did have hope.


 He just wasn't convinced that this DIP was a bad idea.


The "problem" this DIP is supposed to solve (per the poorly 
written DIP) isn't actually solved by the DIP. No answer was 
given to that fact. Other than the actual problem this DIP was 
supposed to be solved will be fixed at a later date by a separate 
DIP.


 Personally, I didn't see any problem with this DIP, since it 
 just tightened down  safe a bit.


Breaking changes, the author took no time to even try to measure 
how wide spread it would be. There are no benefits, the problems 
that are supposed to be solved with it aren't actually solved. 
Not to mention the problem is actually solved just by using the 
GC. Like you are only able to in  safe code anyways.


 Whether the next steps in the "larger goal" are good ones is 
 another matter entirely, and those will be put in a DIP (or 
 multiple DIPs) and argued on their own at some point.


There's no reason for this one to be on it's own. It's useless on 
it's own, causes breaking changes, and who knows what the rest of 
the implementation might end up looking like. This is being done 
all prematurely.


 And if they're bad ideas, then hopefully he will be convinced 
 of that when those DIPs are discussed. Ultimately though, no 
 matter who comes up with the DIP, Walter has to be convinced 
 that it's a good idea. It's just that if it's his DIP, he's 
 already convinced that it's a good idea, so someone has to then 
 convince him otherwise for it to not be accepted.


It's hard to argue against an idea that isn't fully formed. All 
of his arguments against the DIP were based on the fact that 
nothing is implemented. It's easy to say, Oh that'll be fixed in 
Part 2 of a third DIP down the road.


 D wouldn't be what it is today.


You can look at it both ways, in that sense. (Half full glass)

Should create a DIPW process then, duck the foundation and any 
formalities. Which stands for DIPWalter, which simply consists of 
a single step where a single topic tries to convince Walter it's 
a bad idea. Why have two community reviews? Those are made with 
the assumption that the DIP will actually change between the 
reviews. What's the point of a "formal review" when there's just 
Walter talking to himself (rip Andrei). Why waste everyone's time 
on formalities when they obviously are irrelevant?
Oct 22 2019
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:


 Should create a DIPW process then, duck the foundation and any 
 formalities. Which stands for DIPWalter, which simply consists 
 of a single step where a single topic tries to convince Walter 
 it's a bad idea. Why have two community reviews? Those are made 
 with the assumption that the DIP will actually change between 
 the reviews. What's the point of a "formal review" when there's 
 just Walter talking to himself (rip Andrei). Why waste 
 everyone's time on formalities when they obviously are 
 irrelevant?


The formal assessment isn't Walter by himself. Atila took 
Andrei's place in that role. There is no automatic approval. Had 
Atila objected to the DIP, Walter would have had to either 
convince him to come around to his point of view or revise the 
DIP to meet Atila's concerns.
Oct 22 2019
parent Exil <Exil gmall.com> writes:
On Wednesday, 23 October 2019 at 04:49:52 UTC, Mike Parker wrote:

 On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:


 Should create a DIPW process then, duck the foundation and any 
 formalities. Which stands for DIPWalter, which simply consists 
 of a single step where a single topic tries to convince Walter 
 it's a bad idea. Why have two community reviews? Those are 
 made with the assumption that the DIP will actually change 
 between the reviews. What's the point of a "formal review" 
 when there's just Walter talking to himself (rip Andrei). Why 
 waste everyone's time on formalities when they obviously are 
 irrelevant?


 The formal assessment isn't Walter by himself. Atila took 
 Andrei's place in that role. There is no automatic approval. 
 Had Atila objected to the DIP, Walter would have had to either 
 convince him to come around to his point of view or revise the 
 DIP to meet Atila's concerns.


I'd love to see the transcript of that. What was included in the 
DIP was rather short
(a single sentence) compared to other DIPs.
Oct 23 2019
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:


 it's a bad idea. Why have two community reviews? Those are made 
 with the assumption that the DIP will actually change between 
 the reviews.


No, that's not the assumption. You're conflating Community Review 
with Final Review. There can be multiple rounds of the former as 
required and only one of the latter. In a perfect scenario, no 
revisions are required between CR and FR. The purpose of the 
Final Review is to provide one final opportunity to catch any 
major issues that might have been missed during the CR round(s) 
and to allow anyone who missed the CR round(s) a final 
opportunity to have their say. Revisions are expected after a CR 
round, but not after the FR. As the documentation explains:

https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md
Oct 22 2019
parent Exil <Exil gmall.com> writes:
On Wednesday, 23 October 2019 at 04:53:55 UTC, Mike Parker wrote:

 On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:


 it's a bad idea. Why have two community reviews? Those are 
 made with the assumption that the DIP will actually change 
 between the reviews.


 No, that's not the assumption. You're conflating Community 
 Review with Final Review. There can be multiple rounds of the 
 former as required and only one of the latter. In a perfect 
 scenario, no revisions are required between CR and FR. The 
 purpose of the Final Review is to provide one final opportunity 
 to catch any major issues that might have been missed during 
 the CR round(s) and to allow anyone who missed the CR round(s) 
 a final opportunity to have their say. Revisions are expected 
 after a CR round, but not after the FR. As the documentation 
 explains:

 https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md


Why even have a final review then? Shouldn't the community review 
only end if there are no more changes to be made? If changes are 
made after the Final Review, then those changes won't get to be 
reviewed. If the author doesn't take any criticism of their work 
and decides their DIP is a shiny pile of words that doesn't needy 
any more polishing, why have the community review the same thing 
again? If that is how it is intended to be then it is a flawed 
system at that.
Oct 23 2019
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:

 Not to mention the problem is actually solved just by using the 
 GC.


The d language is marked as a system programming language. The GC 
is not going to cut it to a lot of people.(Did you forget the 
whole betterC flag?)

-Alex
Oct 23 2019
parent reply Exil <Exil gmall.com> writes:
On Wednesday, 23 October 2019 at 15:10:23 UTC, 12345swordy wrote:

 On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote:

 Not to mention the problem is actually solved just by using 
 the GC.


 The d language is marked as a system programming language. The 
 GC is not going to cut it to a lot of people.(Did you forget 
 the whole betterC flag?)

 -Alex


A flag that was only added recently (relative to the lifespan of 
D)? D isn't a systems programming language, there's entire 
threads dedicated to the topic. You can call it whatever you 
want, but if that's what it wasn't to identify as, it's bottom of 
the barrel in terms of system programming languages.
Oct 23 2019
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 23 October 2019 at 15:31:24 UTC, Exil wrote:

 D isn't a systems programming language




"“But D has a GC!”, I hear you exclaim. Yes, but it’s also a 
systems programming language with value types and pointers, 
meaning that today, D isn’t memory safe. DIP1000 was a step in 
the right direction, but we have to be memory safe unless 
programmers opt-out via a “I know what I’m doing”  trusted block 
or function. This includes transitioning to  safe by default."

https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

-Alex
Oct 23 2019
parent Exil <Exil gmall.com> writes:
On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote:

 "“But D has a GC!”, I hear you exclaim.


No body said that. Funny how you chose the simplest argument to 
argue against.


 Yes, but it’s also a
 systems programming language with value types and pointers, 
 meaning that today, D isn’t memory safe. DIP1000 was a step in 
 the right direction, but we have to be memory safe unless 
 programmers opt-out via a “I know what I’m doing”  trusted 
 block or function. This includes transitioning to  safe by 
 default."

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

 -Alex


Despite the mess DIP1000 was and still is, it did actually solve 
some problems. Even still there are bugs related to DIP1000 that 
aren't being fixed anymore cause the focus has already shifted 
away from it. The DIP1000 still says it will be "updated" but 
that's most likely never going to happen. Especially considering 
this DIP1021 has an example of a bug that the DIP doesn't even 
fix.

For  safe, it is already safe if you use the GC. If you use  safe 
with DIP1021 you are restricting the user in what code they can 
write and it doesn't make their code any safer. This is just a 
flat restriction for no purpose for them.

For manual memory management, this does not solve the problem 
illustrated by the DIP's example. Especially considering that in 
a blog post (formally unbeknownst to the DIP1021) the intention 
is to introduce a  live attribute. And the actual problem won't 
actually be fixed unless the  live attribute is there.

So it doesn't benefit  safe users, it doesn't benefit manual 
memory management users and it won't come to fruition until some 
future attribute is implemented. I'm all for implementing Rust's 
memory management in D, but this is just horrible project 
management in all regards. Maybe it wouldn't be that big of a 
deal if it was a smaller project where you can muddle through 
finding your way willy nilly, but the whole purpose of the 
formalities -is- should be so you don't do that.
Oct 24 2019
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 20 October 2019 at 12:31:23 UTC, Mike Parker wrote:

 DIP 1021, "Argument Ownership and Function Calls", has been 
 formally accepted with minor revision. It was updated to make 
 clear that the proposal is one piece of a bigger plan.

 https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md


Is there a connection between this DIP and the restrict qualifier 
in C? This DIP basically ensures that in  safe code, if a piece 
of data is accessed only through scope pointers, then there must 
be only one mutable pointer to said data or they are all const. 
That there is only one mutable way to access data sounds like 
restrict to me. I would think that would enable some 
optimizations in  safe code.
Oct 28 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2019 12:23 PM, jmh530 wrote:

 Is there a connection between this DIP and the restrict qualifier in C? This
DIP 
 basically ensures that in  safe code, if a piece of data is accessed only 
 through scope pointers, then there must be only one mutable pointer to said
data 
 or they are all const. That there is only one mutable way to access data
sounds 
 like restrict to me. I would think that would enable some optimizations in
 safe 
 code.


I hadn't thought of that, it is an interesting observation.
Oct 28 2019
parent reply Ben Jones <fake fake.fake> writes:
On Monday, 28 October 2019 at 20:23:50 UTC, Walter Bright wrote:

 On 10/28/2019 12:23 PM, jmh530 wrote:

 Is there a connection between this DIP and the restrict 
 qualifier in C? This DIP basically ensures that in  safe code, 
 if a piece of data is accessed only through scope pointers, 
 then there must be only one mutable pointer to said data or 
 they are all const. That there is only one mutable way to 
 access data sounds like restrict to me. I would think that 
 would enable some optimizations in  safe code.


 I hadn't thought of that, it is an interesting observation.


Just for context, here's a paper arguing restrict without tooling 
is a bad idea: 
http://people.cs.pitt.edu/~mock/papers/clei2004.pdf .  Having the 
compiler enforce it changes the game substantially, I think.
Oct 28 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/28/2019 2:38 PM, Ben Jones wrote:

 Just for context, here's a paper arguing restrict without tooling is a bad
idea: 
 http://people.cs.pitt.edu/~mock/papers/clei2004.pdf .  Having the compiler 
 enforce it changes the game substantially, I think.


I've always known it was a bad idea (not just me, it was common knowledge). 
People have a hard time understanding restrict, and are guaranteed to use it 
wrong. Let alone errors using it from people who do understand it.

Compiler enforcement is the only way to make it go.
Oct 28 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 28 October 2019 at 21:53:50 UTC, Walter Bright wrote:

 I've always known it was a bad idea (not just me, it was common 
 knowledge). People have a hard time understanding restrict, and 
 are guaranteed to use it wrong. Let alone errors using it from 
 people who do understand it.

 Compiler enforcement is the only way to make it go.


It isn't possible to prove it for a compiler in many cases.  Not 
without full verification, and even then it is hard.

So yeah, having it is good, but requiring it isn't competitive 
(vs C restrict).
Nov 05 2019
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 28 October 2019 at 19:23:30 UTC, jmh530 wrote:

 they are all const. That there is only one mutable way to 
 access data sounds like restrict to me.


Well, if you add the constraint that there also is no const way 
to access the data.

But unique ownership is stricter than «restrict», which only 
guarantees that there is no aliasing (overlapping) between the 
pointed-too-memory. No guarantees for there not being other 
pointers to the same memory.

It is basically only significant when accessing arrays, like when 
you are calling a function with two windows onto the same array. 
Proving that the two windows don't overlap is not always possible 
without a performance loss.

Being able to tell the compiler that there is no overlap makes 
sense when doing inline updates in an array, so that the compiler 
can restructure instructions and use SIMD.  Without restrict you 
would often have to write the single array element before reading 
another (as they could point to the same memory location).

BUT «restrict» is very crude. It would probably be better to 
provide more narrow guarantees (e.g. «the offset between the two 
pointers is at least 16 bytes»).
Nov 05 2019