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.

On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton Wakeling wrote:
> Which is: have you considered the possibility that Walter and Andrei are the only people who really know what they're talking about, and everyone else is a [expletive] idiot? :-)

Without being that extreme, yeah, the community has a tendency to immediately assume "W&A are missing something obvious" instead of "W&A are seeing something I'm not".

The fact that W&A seem somewhat bad at communicating their viewpoint (and understanding other people's viewpoint) doesn't help.

On Thursday, 28 February 2019 at 23:15:30 UTC, Olivier FAURE wrote:
> On Thursday, 28 February 2019 at 03:06:37 UTC, Nicholas Wilson wrote:
>> A DIP is only as good as the feedback it receives.
>
> You're saying this like it's self-evident, but it seems very clear to me that it's the very root of your disagreement with Andrei: you believe that the process should involve the reviewers making an effort proportional to the DIP author, whereas Andrei believes that the process should minimize reviewer effort.
>
> Now, neither of these ideas are inherently invalid, but you have to realize they're a trade-off. You're not going to convince Andrei to change the DIP process by saying "The current process wastes the time of DIP authors!", because Andrei is already aware of that. The problem is that is that a process with a heavier involvement from W&A would waste/spend more of *their* time, which Andrei considers a bad trade-off.

Thank you for making that observation.

Yes it is a tradeoff, but we are at one extremum at the moment. I don't think I suggested that the effort of W&A put in prior to the formal assessment should match that of the author, sorry for the confusion if it came across that way. Perhaps I should have said "A DIP improves only as much as the feedback it receives."

(Pedantically I suppose the improvements are bounded by the feedback it receives, since that didn't help 1017 at all.)

> (personally, I can see where he's coming from; there are a lot of people writing DIPs, and only two W&A; any process which requires more involvement from them is going going to see them spending less time on maintaining the compiler, designing features, and whatever else it is they're doing)

Maximising the return on investment of having reviews is important and I believe that there is a lot of low hanging fruit, but the PRIMARY issue it that this whole debacle could have been avoided if W&A had said "We've found some significant issues with this DIP please edit the DIP to fix them." Instead there was no communication at all, they got confused by ambiguities in the DIP and delivered the right verdict (in the sense that e.g. exception handling needs to be accounted for) for COMPLETELY the wrong reasons. Their behaviour that followed was less than stellar.

> (that said, the current process could definitely stand to be improved, and I like the direction Mike is going for)

Yes, I'm expecting quite a few changes to the process in response to issues identified with DIPs 1000, 1015-18 at the DConf Foundation meeting.

On Thursday, 28 February 2019 at 23:17:49 UTC, Olivier FAURE wrote:
> On Tuesday, 26 February 2019 at 22:56:40 UTC, Joseph Rushton Wakeling wrote:
>> Which is: have you considered the possibility that Walter and Andrei are the only people who really know what they're talking about, and everyone else is a [expletive] idiot? :-)
>
> Without being that extreme, yeah, the community has a tendency to immediately assume "W&A are missing something obvious" instead of "W&A are seeing something I'm not".

The fact the they caught that the DIP doesn't specify how it is supposed to behave under exception is a good thing...

> The fact that W&A seem somewhat bad at communicating their viewpoint (and understanding other people's viewpoint) doesn't help.

... therein lies the problem. The good thing is we can fix this by fixing the DIP process to prescribe what should and shouldn't happen when DIP breaking behaviour is discovered post final. Communication with the DIP author is a good start.

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.

On 2/28/2019 3:17 PM, Olivier FAURE wrote:
> 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 agree that the rejection rationale needs to be more detailed and thorough.

On 2/28/2019 3:17 PM, Olivier FAURE wrote:
> Without being that extreme, yeah, the community has a tendency to immediately assume "W&A are missing something obvious" instead of "W&A are seeing something I'm not".

Despite repeated attempts and examples, Andrei and I have been unable to communicate the implicit rvalue conversion problem. I don't know what to do about that. I wish I had Herb Sutter's / Scott Meyers' skills, but I don't.

> The fact that W&A seem somewhat bad at communicating their viewpoint (and understanding other people's viewpoint) doesn't help.

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.

On 2/28/19 8:52 PM, Walter Bright wrote:
> 
> Despite repeated attempts and examples, Andrei and I have been unable to communicate the implicit rvalue conversion problem. I don't know what to do about that. I wish I had Herb Sutter's / Scott Meyers' skills, but I don't.

(Disclaimer: No intention of being contentious here, just a genuine question) Could someone point me to some of these attempts/examples? I'm curious to take a look at them.

My take on all this (not that it counts for anything):

See? This is what happens when you introduce bureaucracy/red-tape to problems. You get the same problems, just with much slower progress.

Frankly, I think we already have far better mechanisms that anything a supposedly-improved DIP process could ever provide: Github reviews and CI tests.

Looking at DIP1016 in particular:

1. Using the same Github code review process we already use to get things done instead of this "The DIP Process" contrivance would have allowed the DIP the flexibility necessary to receive W&A feedback sooner AND respond to such feedback without the "Too bad, go back to start, try again" formality-for-the-sake-of-formality worthlessness.

2. The test suite is going to do a ****FAAAAARRRR**** better job of rooting out technical problems than five years of human-review. Does anyone seriously think it *wouldn't* have caught the issues with 1016 right away? And even if so, does that say more about the DIP process, or does it say more about the test suite?