On 01/03/2017 04:28 AM, Paulo Pinto wrote:
Looking from the outside, and watching what was reached from 2016
roadmap, it is clear the DIPs evaluated thus dar aren't about fixing the
library or runtime issues that prevent D's adoption at large as a
systems programming language.
Meanwhile Swift, Go and Rust have a clear roadmap how their future is
supposed to look like, and drive just in that direction, with C++ taking
all remaining good D ideas.
This DIP discussion and the latest ones about splitting the runtime
again, don't do anything to earn D any credibility it might still have
left.
Thanks for taking the time to write this. All languages have an
improvement process, which runs as a background task that is not always
correlated with the current principal objectives of the language's
leadership. We have recently improved our DIP process, but positive
examples of compelling DIPs are missing. We were facing the problem that
upcoming DIPs, if unguided, could create busywork for the leadership on
trivial matters. Whether approved, rejected, or put on hold, DIP1005
will serve as a yardstick for future DIPs regarding the necessary work
involved in defining the problem, investigating it as rigorously as
possible, comparing with alternatives, and defining the feature.
Walter and I do agree that the DIP is ahead of its time because (a)
there are more pressing and more important matters to keep me busy, and
(b) encapsulation in D is a larger topic that we haven't yet put front
and center because of (a).
For DIP1005 I invite interested collaborators to contact me about future
iterations; it is important for the matter of encapsulation and also for
the meta-challenge of setting an example for other DIPs to follow. Thanks.
Andrei
