The DIP Process

Olivier FAURE couteaubleu at gmail.com
Thu Feb 28 23:17:15 UTC 2019


On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright 
wrote:
> 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.

If that's the direction you're going for, then the rejection 
rationale needs to be a little more polished than DIP-1016's was.

I understand that reviewer time is limited, but the rejection 
rationale is especially important, not just for the sake of the 
DIP author, but for the sake of everyone comes after him.

In particular, at some point in the post-rejection debate, Andrei 
wrote:

> It must be clear that the reason of this misunderstanding is 
> squarely due to the DIP itself. It has multiple problems of 
> informality and vague language that have worked together to 
> cause said misunderstanding.
>
> [...]
>
> So the code with my_short was open to interpretation. Cool. In 
> a thorough submission, however, there would have been many 
> places that clear that up:
>
> * Use of a distinct notation (non-code non-text font for 
> metalanguage, i.e. general expressions);
>
> * 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.

Now, this? This is *exactly* what the rejection rationale should 
have been in the first place. The current rejection rationale 
gives a few points of contention, but they're almost secondary. 
The quote above actually points out the root cause of the 
rejection, and what steps need to be taken to fix it.

Again, I understand there's a trade-off at work, but if you want 
the quality of submitted DIPs to increase over time, you need to 
put some effort into explaining why you reject certain DIPs.


More information about the Digitalmars-d mailing list