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.

Reply via email to