The DIP Process

[Walter Bright]

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.