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.

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.

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.

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.

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.

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.