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.
