The DIP Process

[Paolo Invernizzi]

On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright 
wrote:
> I propose that rejecting a DIP is NOT wasted effort.
>
> Most language ideas come up again and again. If an idea is 
> rejected early in the process, it will come up again and people 
> will have to rediscover the thought process for why it was 
> rejected. The worst case will be not rediscovering the why, 
> then implement it, and find out the hard way.
>
> For example, we were pretty far along in the automatic ref 
> counting thing until Timon found a fundamental flaw in it that 
> everyone missed. It sunk the whole thing, we couldn't find a 
> way to make it memory safe.
>
> ARC keeps coming up again and again. But we don't have a DIP to 
> point to to show the fatal flaw, and we just have to remember 
> to point it out again.
>
> A rejected DIP comes with a rationale, so anyone trying to 
> resurrect the idea will have a starting point for both the new 
> proposal and will be prepared to surmount the objections, which 
> will save a lot of grief. If they've got nothing new to add, 
> they'll save a lot of time repeating the failure.
>
> Rejected DIPs also form a basis and a standard for future DIPs. 
> Andrei and I have both noticed that C++ proposals have gotten 
> steadily better over the years.
> DIPs - rejected and accepted - form the corpus of knowledge 
> that make up what and why D is what it is.
>
> For another example, analyzing failed military campaigns is 
> just as useful as studying successful ones.
>
> ---
>
> Tl,Dr: Rejecting a completed DIP wastes time in the short term, 
> but saves time in the long term.

 From one side, there's the need to attract more 'voluntary' work 
towards the D ecosystem, and from the other side there's the need 
to save time of who is already involved, and that's reasonable.

Most of the DIP work is done by voluntaries, in their spare time, 
reality is that they are not payed researchers submitting papers 
to payed journals reviewer.

I know that you are a really pragmatic man, so I will suggest you 
and Andrei to just use a pragmatic and simple way of moving.

I'm assuming that the DIP is _already_ in a good shape, or the 
community review process has something wrong, which does not seem 
to me the case, actually.

Give credits, to the author and to the community: if it seems so 
strange to you that, eg. Manu, have not seen the "big hole" 
that's involved in the DIP, simply contact him during the review, 
and ask for clarification to dispel the doubts. Open a channel.

If you both agree that the DIP has the _potential_ of having 
value, just provide feedback and encourage the author to emend 
the part that are not yet perfectly shaped, and mentor him during 
that part.

You have foreseen value, a LOT of work was already done by the 
community, now it's W&A turn to contribute with the final 
touches, that the community was not able to property see and 
handle. That's is almost always not a big work to do, shape 
together the DIP towards the final accepted shape.

There's not better time spent that working side by side with a 
volunteer on that, IMHO, and it's a great way to thanks them for 
the effort they have put in the process.

Respectfully,
Paolo