The DIP Process

[Nicholas Wilson]

On Friday, 1 March 2019 at 00:27:23 UTC, Olivier FAURE wrote:
> On Tuesday, 26 February 2019 at 22:16:09 UTC, Manu wrote:
>> 4. Off the back of extensive discussion while trying to dig out
>> details, while also being insulted, it was concluded that 
>> there are 2
>> minor and self-contained issues.
>
> We strongly disagree on this one.
>
> Your opinion is, explicitly, that the only criticisms of the 
> DIP were about the lack of exception support and the "ref to 
> implicit cast" issue (your "bad choice of variable name"), and 
> that the DIP would have been accepted if not for them. You 
> especially insist on the "one word" part, and seem pretty 
> confident that this word completely changed the final result.
>
> This is *not* what W&A have said. In that, they have said, 
> multiple times, that these problems were *symptoms* of the lack 
> of polish of the proposal, and that the DIP couldn't be 
> accepted until that lack of polish was corrected.
>
> Notably, Andrei has said:
>
>> So if we rejected the DIP, we didn't do so on account of one 
>> word that can be so easily changed; we did so on account of a 
>> DIP that as a whole failed to clarify what it purports to do 
>> (and equally importantly, to not do).
>
> (https://forum.dlang.org/post/q2u429$1cmg$1@digitalmars.com)
>
> in a post that you haven't answered.
>
> Now, I agree with you that there were problems in the process, 
> and that the rejection rationale posted on Github was pretty 
> unhelpful, and just plain bad.
>
> But that idea you have that "W&A stubbornly refuse to 
> reconsider their decision based on a few lines they 
> misunderstood" is just inaccurate.

The point is that that is not _actionable_, for two reasons:
1) the rejection rationale is wrong and until the reasons for 
rejection reflect the problems nothing can be done to improve the 
DIP, and
2) attempts to do so have been rejected

>>   c. The second is that the formal review fell off the wagon on
>> account of one variable name, and used that to build a large 
>> fantasy
>> about what the text intended, which was in conflict to the 
>> heading
>> *immediately above* (and the DIP title, and the brief, and 
>> plenty of
>> points elsewhere)
>>     - Surely the reviewers must have found the conflict with 
>> the title
>> immediately above odd, and perhaps might have considered 
>> seeking
>> clarification rather than repeatedly insult me about it
>
> During the whole process, you've insisted a lot that "we're 
> talking about r-values, so obviously [ref to cast of lvalue] 
> doesn't apply".
>
> But there is no strict definition, as-is, of what is or isn't a 
> rvalue. In fact, Walter has said:
>
>> That's why it's problematic to have a rule that rvalues can be 
>> implicitly converted, but not lvalues. There's not a hard line 
>> between lvalues and rvalues.
>
> (https://forum.dlang.org/post/q2vr50$1lga$1@digitalmars.com)
>
> The DIP as it stands doesn't address how to differentiate 
> lvalues from rvalues in cases like "symbol[expr]", 
> "symbol.symbol", "symbol.symbol[expr]", "cast(type)expr", etc.

They could all be reasonable categorised a rvalue that arise from 
lvalues.

> Now, you might say (and have said in the past) "Well that's 
> obvious, you just need to do X, unless Y, in which case Z", but 
> the point is that all these considerations *need to be in the 
> proposal*.

I agree, but see point 2 above.


> As it is, the proposal doesn't have any negative space. That 
> is, it explains what the feature should look like, but it 
> doesn't define boundaries, where the feature is or isn't 
> allowed to be used.
>
> Defining negative space is important because it's how you find 
> corner cases, cases where the correct behavior seems obvious, 
> and yet when you spell it out it turns out everyone disagrees 
> on how it should be handled.

That is a really great analogy, I like it!

> Right now, the DIP doesn't address at all potential corner 
> cases like alias this, return ref, auto ref, refs in foreach, 
> casts, etc.
>
> ---
>
> tl;dr: There were major problems in how W&A handled DIP 1016, 
> but saying it was rejected because of "a single world" is 
> inacurate.

A hyperbole yes...

> It had major structural problems that could not be fixed with a 
> few minor changes.

... but the DIP is very sensitive (in the mathematical sense: 
∂|review|/∂|DIP| (where || is the edit distance) is absolutely 
massive) and no recourse was given. What would the required edit 
distance be? Hard to say, because it is currently in the domain 
of the review is at fault. That _must_ be fixed before the DIP 
can be improved, but see point 2 above.