The DIP Process

[Nicholas Wilson]

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.