On Thursday, 6 September 2018 at 17:44:28 UTC, Jonathan M Davis
wrote:
Of course, what further complicates things here is that the
author is Walter, and ultimately, it's Walter and Andrei who
make the decision on their own. And if Walter doesn't respond
to any of the feedback or address it in the DIP, it all comes
across as if the DIP itself is just a formality. The fact that
he wrote a DIP and presented it for feedback is definitely
better than him simply implementing it, since it does give him
the chance to get feedback on the plan and improve upon it, but
if he then doesn't change anything or even respond to any of
the review comments, then it makes it seem kind of pointless
that he bothered with a DIP. At that point, it just serves as
documentation of his intentions.
This is all in stark contrast to the case where someone other
than Walter or Andrei wrote the DIP, and the author doesn't
bother to even respond to the feedback let alone incorporate
it, since they then at least still have to get the DIP past
Walter and Andrei, and if the DIP has not taken any of the
feedback into account, then presumably, it stands a much worse
chance of making it through. On the other hand, if the DIP
comes from Walter or Andrei, they only have the other person to
convince, and that makes it at least seem like there's a decent
chance that it's just going to be rubber-stamped when the DIP
author doesn't even respond to feedback.
I think that it's great for Walter and Andrei to need to put
big changes through the DIP process just like the rest of us
do, but given that they're the only ones deciding what's
accepted, it makes the whole thing rather weird when a DIP
comes from them.
- Jonathan M Davis
If Walter had tried to implement this w/o a DIP, that would have
been among the first reviews received, so it is good that he's
has done it as a DIP. But not using it for improving the design
is almost as bad.
I view this DIP like DIP1000 but worse: at least with DIP1000
there was clear motivation, and despite any breakage and poor
documentation of continued changes due to unforeseen
requirements, it solves a real problem and has bought real value.
It could have been handled much better, but is a net positive IMO.
DIP1017 OTOH has flawed/unsubstantiated motivation, will break
lots of code, and solves a problem that is already solved by
GDC/LDC where the only benefit other that documentation is faster
code and could be solved in the same way as GDC/LDC with none of
the breakage and complications.
Any marginal benefits in speed of compiled code for DMD _only_
(which is not why one uses DMD) comes at the cost of:
opportunity cost of development/review and ongoing implementation
fixes;
unknown but probably very large code breakages;
slower compile times for all three compilers;
increased complexity in the type system and for new users;
and all the other reasons listed in the draft and community
review.
IMO, a very much net negative
I now understand why Mihails left over DIP1000...
