www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Priority DIP for Draft Review: Argument Ownership and Function Calls

reply Mike Parker <aldacron gmail.com> writes:
Walter has a DIP currently in Draft Review that is a critical 
feature for the implementation of safe ref counting. It needs to 
have priority through the DIP process.

Before I move it to Community Review, it should be vetted for a 
couple of weeks in the Draft Review. Anyone who has the time and 
interest, please cast your eyes upon it and attempt to destroy it 
to the best of your ability:


https://github.com/dlang/DIPs/pull/158


To be clear, this DIP will not hold up the process for anyone 
else. The new schedule means that normally, there is one DIP in 
Community Review beginning the first week of a month, one DIP in 
Final Review beginning the third week of a month, and one DIP in 
Formal Assessment beginning the first week of a month. When a DIP 
needs priority, or when other circumstances warrant it, I may run 
other another DIP review in parallel with any other review round.

Here's my current schedule for upcoming DIPs:

DIP 1020 Community Review Round 2: Starts sometime next week. I'm 
awaiting a PR from the DIP author with the necessary revisions.

DIP 1019 Final Review: This will begin at some point in the week 
of July 17.

DIP 1021 Community Review Round 1: Depending on how the Draft 
Review goes, Walter's proposal will become DIP 1021. I plan to 
begin the first round of CR in parallel with the Final Review of 
DIP 1019.

DIP 1022 Community Review Round 1: The current candidate for DIP 
1022 is the "Multiple Template Constraints" proposal:

https://github.com/dlang/DIPs/pull/131

If that's not ready in time, the next candidate is the "Foreach 
auto ref" proposal:

https://github.com/dlang/DIPs/pull/133

Whichever one get the nod will begin the first round of CR in the 
first week of August. If you haven't yet participated in the 
Draft Review for either, please give them a look.

DIP 1020 Final Review: Assuming the second round of CR is the 
last, this review will kick off in the third week of August.

Given that 1019 and 1020 are essentially alternate proposals for 
the same feature, I'll be making an exception for the Formal 
Assessment and run them both in parallel. I'll hand them both off 
to Walter and Atila in the first week of September.
Jun 26
next sibling parent reply Olivier FAURE <couteaubleu gmail.com> writes:
On Wednesday, 26 June 2019 at 10:51:33 UTC, Mike Parker wrote:
 https://github.com/dlang/DIPs/pull/158
I'm going to be candid here: Based on past experience, I'm worried that: - This DIP will generate a lot of negative feedback. - Walter will ignore most of that feedback, or cherry-pick a few arguments that resonate with him, and ignore the others. - People will ask for a more formal specification, and Walter will refuse on the ground that he isn't a PL theorist / that the DIP is only a first step towards a more complete borrowing scheme. - Walter will not lay out what that complete borrowing scheme looks like, on the grounds that it's too early to tell. - Because of its importance for future features, the DIP is going to be rushed despite the unnadressed criticisms. Can we get some assurance this isn't going to be the case? I'm particularly interested in flow analysis features, and I think I have something to contribute, but I don't want to spend a large amount of effort debating and suggesting alternatives if I expect to be stonewalled.
Jun 28
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 28 June 2019 at 07:22:56 UTC, Olivier FAURE wrote:
 On Wednesday, 26 June 2019 at 10:51:33 UTC, Mike Parker wrote:
 https://github.com/dlang/DIPs/pull/158
I'm going to be candid here: Based on past experience, I'm worried that: - This DIP will generate a lot of negative feedback. - Walter will ignore most of that feedback, or cherry-pick a few arguments that resonate with him, and ignore the others. - People will ask for a more formal specification, and Walter will refuse on the ground that he isn't a PL theorist / that the DIP is only a first step towards a more complete borrowing scheme. - Walter will not lay out what that complete borrowing scheme looks like, on the grounds that it's too early to tell. - Because of its importance for future features, the DIP is going to be rushed despite the unnadressed criticisms. Can we get some assurance this isn't going to be the case? I'm particularly interested in flow analysis features, and I think I have something to contribute, but I don't want to spend a large amount of effort debating and suggesting alternatives if I expect to be stonewalled.
It's up to the discretion of *every* DIP author whether to act on feedback from the review rounds. DIP authors are required to address DIPs in the review threads, but they are not required to address them via revision. You will have your chance to provide your feedback, but no one is going to guarantee that your feedback will lead to changes. This DIP will not be rushed through. The review process starts with the first Community Review round. Once that happens, it will follow the same (recently revised) schedule as every DIP currently does.
Jun 28
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 28 June 2019 at 07:52:59 UTC, Mike Parker wrote:


 address DIPs in the review threads, but they are not required
I meant to say they're required to address *feedback* in the review threads.
Jun 28
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 28 June 2019 at 07:22:56 UTC, Olivier FAURE wrote:
 I'm particularly interested in flow analysis features, and I 
 think I have something to contribute, but I don't want to spend 
 a large amount of effort debating and suggesting alternatives 
 if I expect to be stonewalled.
It seems general fear of flow analysis is that people will ask it to be perfect and it would be difficult to stop it from growing in complexity.
Jun 28
prev sibling parent Newbie2019 <newbie2019 gmail.com> writes:
On Wednesday, 26 June 2019 at 10:51:33 UTC, Mike Parker wrote:
 Walter has a DIP currently in Draft Review that is a critical 
 feature for the implementation of safe ref counting. It needs 
 to have priority through the DIP process.

 Before I move it to Community Review, it should be vetted for a 
 couple of weeks in the Draft Review. Anyone who has the time 
 and interest, please cast your eyes upon it and attempt to 
 destroy it to the best of your ability:
Even I may not fully understand it, I still vote to support this DIPs. The limits is clear and only effect the "bugs prone" double scope ref code, this kind code should be addressed anyway. I do like D have full borrow check/static interface without runtime cost very much(the rust style), but we already has dip1000 why not make it more safe and move on.
Jun 28