Announcing new DIP handling process

[ZombineDev via Digitalmars-d-announce]

On Saturday, 9 July 2016 at 21:21:54 UTC, Dicebot wrote:
> On 07/09/2016 09:11 PM, ZombineDev wrote:
>> Can the new DIP process be used to evaluate library proposals? 
>> That way a high level design could be fleshed out and approved 
>> before the contributor goes too far with implementing a design 
>> which would be rejected.
>
> It is quite hard. To reasonably evaluate library proposal one 
> has to have at least proof of concept implementation showing 
> intended API. It isn't easy to fit into abstract DIP format.

It depends on the domain and scope of the proposal. See for 
example the C++17 file system API: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html#class-path. I think you'll agree that such a proposal can easily be evaluated solely on its interface, without any need to look at the implementation.

In other domains, such as algorithms, metaprogramming and 
concurrency / parallelism a proof of concept is much more needed.

I think the main question is: Is this design feasible? If there's 
any doubt, a proof of concept should be required.

> I can't advise much on this part because I have been trying to 
> stay away from Phobos affairs for a long time and don't know 
> existing status quo about it.

The status quo is that all larger library additions should be 
approved by Walter or Andrei and new modules should go through 
the review process http://wiki.dlang.org/Review/Process. What I 
currently find missing in the review process is a way to get a 
consensus on the high-level design. If a larger design issue is 
brought up during the review process it may require a significant 
rewrite which is a waste of the contributor's time and can be 
very demotivating.