On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu wrote:
> On 2/25/19 1:06 AM, Nicholas Wilson wrote:
>> On Monday, 25 February 2019 at 02:56:13 UTC, Walter Bright wrote:
>>> Your DIP, and nobody else is going to do it, so it falls to me.
>> 
>> It will be reviewed at Dconf, please make sure you have an _accurate_ summary of your criticisms of the DIP ready for then.
>
> This seems to be a misunderstanding of protocol. A negative review is simply a signal that the submission has not been strong enough. As such, the submission, not the review, needs to be improved.

I'm not suggesting that the DIP is perfect, nor that it was without ambiguities and misunderstandings, nor that is can't/doesn't need to be improved.
What _is_ important is that the time spent on improving it covered that areas that actually need improvement, and given the misunderstandings on all sides, a useful starting point is the set of problems the reviewers have identified crosschecked by the authors. That is not an unreasonable request.

> There are similarities and differences between our DIP process and paper submission reviews at conferences and journals everywhere; one key similarity is that the submitters are on hook for providing convincing submissions, whereas reviewers are not required to defend their reviews. It's an asymmetric relationship that occasionally frustrates, but it is as such for good reason and it works.

I've said before that that comparison is weak and not particularly useful, irrespective of  its intention.

> It is not a matter of misunderstanding 1-2 sentences, but a problem of precision in specification that needs to be approached with due care.

I believe it is both, which is the basis for the opinion that resubmission is not the appropriate course of action to make best use of everyone's time.

> * Description of the typechecking process, with examples of code that passes and code that fails;
>
> * A clarification that lowering proceeds not against all expressions, but only against rvalues;
> 
> * Several places in text in which it is explained that rvalues resulted from implicit conversions are not eligible;
>
> * etc. etc. etc.

That is a good start, though I suspect that the list is not complete given the last item.

> It is not desirable to demand reviewers to do more work on the review or to defend it.

On the contrary, if we believe your reasoning to be unsound or misguided (irrespective of who is at fault) then clarification and resolution are the only appropriate courses of action.

> Acceptance by bullying is unlikely to create good results.

I agree, but that has not happened here.

> The target of work is squarely the proposal itself.
>
> Our understanding after Manu asked for action items was that he would be up for the work in short order.

The keyword here is "short". By suggesting that the action required is to rewrite, the order is most definitely not short. Time is a valuable resource, and a new DIP from scratch through the DIP process takes a lot of it.

On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote:
> On 2/25/19 3:23 PM, Jacob Carlborg wrote:
>> On 2019-02-25 20:24, Mike Parker wrote:
>> 
>>>  From the process document:
>>>
>>> “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.”
>> 
>> Having it documented doesn't make it less flawed.
>
> Jacob, are there amends you need to make to the DIP?

This whole reply chain sounds more like the problems lie with the DIP process not this DIP, but  I'll let Jacob answer that.

On Tuesday, 26 February 2019 at 00:23:19 UTC, Nicholas Wilson wrote:
> On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu wrote:
>> * etc. etc. etc.
>
> That is a good start, though I suspect that the list is not complete given the last item.

Oh, it keeps going.

On 2/25/19 6:09 PM, Olivier FAURE wrote:
> Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes sense that it was fast-tracked, because it fits a priority of the project owners (C++ interoperability + reference counting) and project owners are allowed to have priorities. It's not like this DIP was rushed or has major vulnerabilities (the "mutable copy constructor" thing is necessary for reference counting).

I haven't heard the final decision from Walter yet, but I proposed that in the interest of quality, we will go through the customary two weeks reviews with DIP 1018.

On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 2/25/19 2:41 PM, bachmeier wrote:
> > On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
> >
> >> From the process document:
> >>
> >> “the DIP Manager or the Language Maintainers may allow for exceptions which waive requirements or responsibilities at their discretion.”
> >>
> >> If you were to write a DIP for a feature they think important enough, it could be fast tracked, too.
> >
> > I hate to be so negative, but when I see D's corporate management structure, the lack of community contribution is obvious. It doesn't exactly motivate contributions. This is no way to run an open source project. I understand that it works well for Facebook because everyone on the team is paid six figures, and they can be replaced in two hours, but an open source project is not Facebook.
> >
> > I know the whole argument about why it is that way. That doesn't mean it's going to work.
>
> What do you recommend? Should we carry a final review here?

In my case, you could have produced useful and not-completely-wrong
rejection text with the rejection, and then not insulted me a few
times before eventually producing some actionable feedback.
I mean, its in your interest to foster contribution, not repel it.

On 2/25/19 7:23 PM, Nicholas Wilson wrote:
>> There are similarities and differences between our DIP process and paper submission reviews at conferences and journals everywhere; one key similarity is that the submitters are on hook for providing convincing submissions, whereas reviewers are not required to defend their reviews. It's an asymmetric relationship that occasionally frustrates, but it is as such for good reason and it works.
> 
> I've said before that that comparison is weak and not particularly useful, irrespective of  its intention.

That you've said it before does not make it any more correct. We have intently modeled the acceptance process after that used by the review process used by conferences, journals, and standardization committees - naturally from the communities I have some familiarity with (Programming Languages, Machine Learning, Natural Language Processing, Algorithms, ISO C++). So the alleged similarities are more of a statement of fact than a metaphor.

There are differences, too, of which the public discussions in this forum is the main one. This is in danger of getting abused; open discussions around DIPs in this forum give the false impression that DIP authors have the authority to demand any extent of explanation and justification of a decision. We do not have the capacity to do that, and it would not be anymore appropriate than journal reviewers being required to provide detailed feedback to submitters' satisfaction. This whole notion of a meeting whereby Walter is grilled by a committee on why exactly he rejected DIP 1016 is Kafkaesque.

> The keyword here is "short". By suggesting that the action required is to rewrite, the order is most definitely not short. Time is a valuable resource, and a new DIP from scratch through the DIP process takes a lot of it.

You can count on me to massage the bureaucracy out of the process if that's the bottleneck. The most significant bit is to focus on working together toward making the proposal better, as opposed to focusing on negotiating acceptance. But whether the DIP keeps the number or gets another one, if the revised document is a 95% cut and paste of the existing one, the review is liable to be a 95% cut and paste of the existing one.

On 2/25/19 9:26 PM, Manu wrote:
> On Mon, Feb 25, 2019 at 12:20 PM Andrei Alexandrescu via
> Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> On 2/25/19 2:41 PM, bachmeier wrote:
>>> On Monday, 25 February 2019 at 19:24:55 UTC, Mike Parker wrote:
>>>
>>>>  From the process document:
>>>>
>>>> “the DIP Manager or the Language Maintainers may allow for exceptions
>>>> which waive requirements or responsibilities at their discretion.”
>>>>
>>>> If you were to write a DIP for a feature they think important enough,
>>>> it could be fast tracked, too.
>>>
>>> I hate to be so negative, but when I see D's corporate management
>>> structure, the lack of community contribution is obvious. It doesn't
>>> exactly motivate contributions. This is no way to run an open source
>>> project. I understand that it works well for Facebook because everyone
>>> on the team is paid six figures, and they can be replaced in two hours,
>>> but an open source project is not Facebook.
>>>
>>> I know the whole argument about why it is that way. That doesn't mean
>>> it's going to work.
>>
>> What do you recommend? Should we carry a final review here?
> 
> In my case, you could have produced useful and not-completely-wrong
> rejection text with the rejection, and then not insulted me a few
> times before eventually producing some actionable feedback.
> I mean, its in your interest to foster contribution, not repel it.

I apologize again for my use of unkind words. If there's something else I can do to atone, please let me know.

On Mon, Feb 25, 2019 at 3:10 PM Olivier FAURE via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 25 February 2019 at 16:00:54 UTC, Andrei Alexandrescu wrote:
> > Thorough feedback has been given, likely more so than for any other submission. A summary for the recommended steps to take can be found here:
> >
> > https://forum.dlang.org/post/q2u429$1cmg$1@digitalmars.com
> >
> > It is not desirable to demand reviewers to do more work on the review or to defend it. Acceptance by bullying is unlikely to create good results. The target of work is squarely the proposal itself.
>
> Agreed.
>
> Honestly, I am not impressed with the behavior of several members here.
>
> I understand that the rvalue DIP went through a long process, that some people really wanted it to be accepted, and that it was frustrating to wait so long only for it to be refused, but at some point, you guys have to accept that the people in charge refused it.

No, you've missed the point **completely**.
I'm not even remotely surprised it was rejected, I never imagined that
I'd change peoples minds on this after trying to do so for 10 years
running.

> They explained why they did, their reasons matched
> concerns other users had, and they explained how to move the
> proposal forward.

This sentence couldn't be more wrong.

I'm going to write this again because you prompted me to, I've said it
elsewhere lots, but apparently you've missed it;
What pissed me off was that the rejection text was almost completely
wrong, it almost felt like they just skimmed it and made up details
according to presumption, and then when I raised the topic on what was
actually wrong looking for actionable feedback, it was made clear that
it was not open to amendment, I *must* write a whole new DIP and
completely reboot the process because all the text was rubbish, and I
should employ someone else competent to do it with me. Then I was
insulted a couple more times; it was implied that the DIP was so bad I
didn't even understand the implications of my own text (I did), and
that it had holes large enough to drive a truck through (it
doesn't)... and only then after a few cycles of referring to the
*actual* text that was written, it was conceded that those criticisms
were indeed incorrect, and then we were able to arrive at some useful
feedback, all of which is of trivial-amendment magnitude; fix the
rewrite to address exceptions, and add some additional text to clarify
a point of misunderstanding that I thought I couldn't have made more
clear if I tried.
Even at the tail end of that though, the result remained the same:
rewrite the DIP, reboot the process, another few hundred days later...
it was expressly rejected that an amendment would be accepted for
consideration, despite agreeing at the end of the thread that that's
all that's required to address the *true* criticisms.

That was a worthless experience, and it didn't help anyone.

> So again, I get that this is frustrating, but repeatedly complaining and asking for an appeal and protesting about other DIPs being accepted is *not* professional behavior.

I'm not a bloody professional, I'm a volunteer!
I do think it would have been useful to amend the rejection text to be
true at the very least, and match the proposal that is written.
I held that position before the thread had played out to where useful
action points emerged, simply because I wanted to have any idea how to
move forward. At the conclusion of that thread, we have the data, and
I don't care, although still no path to have it reconsidered with
amendments, and I'm not gonna take a few hundred more days to start
over.

The reason I bring it up here is not that I'm salty (I am), but
because I'm literally astonished that it's been agreed it's fine that
a copy constructor can mutate the source... and I can't help but draw
contrast to the exact same sorts of arguments that people were using
to break my DIP, and countless other proposals that I've seen over the
years. My DIP was just one of very very many instances of where this
class of issue (unexpected mutation of caller-owned data) would be
used to destroy something, but we're accepting it here at a very
fundamental level of the language.
I just can't see how it's fine in this case, after being show-stopping
for as long as I've been watching.

And to circle right back to the start; I suspect the only reason that
it's considered acceptable here, is that this is an issue of extremely
high importance, and nobody has any better ideas.
To repeat my comment; the problem as I see it, is that `const` as
defined is extremely problematic, and rather than address that hard
issue, we'll just make a compromise in this case.

Anyway, I actually support this DIP, I'm for practical solutions to problems... the only point I was trying to make at the start of this thread is that this sets a precedent, which if we're fair, requires a re-examination of so many rejected ideas gone by.

On 2/25/2019 3:09 PM, Olivier FAURE wrote:
> Yes, this DIP was fast-tracked. Yes, this can feel unfair. And yet, it makes sense that it was fast-tracked, because it fits a priority of the project owners (C++ interoperability + reference counting) and project owners are allowed to have priorities. It's not like this DIP was rushed or has major vulnerabilities (the "mutable copy constructor" thing is necessary for reference counting).

And yes, it underwent major rewrites as Razvan can confirm :-)

On 2/25/2019 6:26 PM, Andrei Alexandrescu wrote:
> I haven't heard the final decision from Walter yet, but I proposed that in the interest of quality, we will go through the customary two weeks reviews with DIP 1018.

I approved it.