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.

On 2/26/2019 5:34 PM, H. S. Teoh wrote:
> Anyway, if anything were to change with alias this, we'd better have a
> darned good replacement for it, because I'll be expecting it!

Any discussion of alias this should be in a separate thread, but for here it suffices to say it was admitted into the language without nearly enough review.

On Thursday, 28 February 2019 at 06:03:00 UTC, Walter Bright wrote:
> I propose that rejecting a DIP is NOT wasted effort.

Not a priori, no...

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

... and yes, this establishes that equivalence to memory unsafety as a basis for rejection of proposals, ...

> A rejected DIP comes with a rationale,

... but it helps no-one if the rationale has no basis in fact, especially if that rationale is left as is.

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

Yes. And? This misses the point, yet again, that the problem is NOT the _outcome_ of the DIP (the DIP does have problems, e.g. exception handling), the problem is the _process_ that results in rejection on a false basis.

> Tl,Dr: Rejecting a completed DIP wastes time in the short term, but saves time in the long term.

... if, and only if, the process is amended to avoid the problems observed with the process as a result of the DIP.

On 2/26/19 6:28 AM, Mike Parker wrote:
> https://www.python.org/dev/peps/pep-0001/#start-with-an-idea-for-python
> 
> The core of the process is the same. What they add to it is this:
> 
> "The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Posting to the comp.lang.python newsgroup (a.k.a. python-list@python.org mailing list) or the python-ideas@python.org mailing list is the best way to go about this.

I strongly agree that's the right way to do things. In fact, we already do it that way in D. But there's one key difference between the way Python does that and the way D does it: When *we* do that here in D, the post is immediately followed by a public lynching at having had THE NERVE to suggest an idea change without writing both a complete DIP and PR first.

On Wed, Feb 27, 2019 at 3:15 PM Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 02/26/2019 11:46 PM, NaN wrote:
> > On Tuesday, 26 February 2019 at 18:22:09 UTC, Andrei Alexandrescu wrote:
> >> On 2/26/19 12:46 PM, Jonathan Marler wrote:
> >>
> >> I'm not sure how we can improve this from the top,
> >
> > You can require the same accuracy and rigour from the review as you do from the DIP. Unless you think that yourself and Walter are infallible then the review process is fundamentally flawed. Dip in, one guy reviews, result out, decision final will result in flawed reviews and disillusioned contributors.
>
> Thanks for writing. We are not able, and should not aspire, to provide a review at the same level of accuracy as the DIP. The onus to convince is squarely on the DIP. This is in keeping for all related review processes I know of.
>
> However, this is good pressure for us to produce good DIPs, together with all other proposers.
>
> I understand rejection of a DIP creates frustration,

What's frustrating is how people keep misrepresenting the conversation this way.

> but at a level it
> needs to be understood by the community that it is a normal and expected
> part of the process.

We're not talking about rejection, we're talking about the process
alone, and how it's configured to practically assure failure unless
you're reviewing them along the way.
Without a single feedback cycle from the stakeholders, and in light of
positive community reviews, there's literally nothing I can do to have
more or less confidence.
It's at your whim to misinterpret a variable name and lose your
mind... or not. I can't know what you're going to do on that morning,
and at that stage, the process says I have absolutely no recourse for
correction, and I was repeatedly told to start over at the back of the
queue, despite the review being almost totally wrong on account of one
word and no provision for amendment.

> The cure is improving the quality of DIPs.

This is a function of feedback. I had zero feedback cycles, and you got all hung up on one word... so, I change that word, and then what? We wait a year and see if there was something else?

> The main
> liability in accepting a DIP that is not suitable is it creates
> precedent for other unsuitable DIP to get in, in a descending spiral of
> quality.

Nobody has ever suggested at any time that an unsuitable DIP should be accepted. Are you deliberately misrepresenting this conversation?

Anyway, Walter's on this now. Fortunately, he'll have his own feedback along the way. I don't expect he'll require that he wait a year to fix a typo.

On Wed, Feb 27, 2019 at 10:05 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> 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.

Wow...
I'm speechless.

How can you write this email with a straight face?
You can't possibly write this and then not go back and correct your
rejection text. There's an exception issue; easily amendable, and then
the rest was a misreading due to a misunderstood variable name and
then a gloss over anything else ("found other issues with the
proposal, most of which may have been remedied through simple
revision"); completely unhelpful.

"it will come up again and people will have to rediscover the thought
process for why it was rejected" - WB
"A rejected DIP comes with a rationale" - WB
"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"
- WB

I'd also like to know why it was rejected, and I think that should be
clearly stated at the bottom. I feel like it's not the first time I've
said this.
What's written there now is worthless to posterity.

Anyway, it's your DIP now.

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

On 2/28/2019 12:31 AM, Manu wrote:
> Anyway, it's your DIP now.

Indeed, and you, Nicholas and everyone else will have the opportunity to destroy it.

On Wednesday, 27 February 2019 at 21:02:44 UTC, Mike Parker wrote:
> no feedback from Walter and/or Andrei at this stage would mean approval is guaranteed.

I think you dropped a "not" here.

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.

(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)

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