DIP 1018--The Copy Constructor--Formal Review

[Nicholas Wilson]

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.