DIP Draft Reviews

[Nicholas Wilson]

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...