The DIP Process

[Olivier FAURE]

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.

>   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.

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*.

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.

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. 
It had major structural problems that could not be fixed with a 
few minor changes.