On Tuesday, 23 August 2016 at 18:37:46 UTC, Dicebot wrote:
By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place.
Well the fact that we have a public review and can criticize the proposal is as much as you can get from a peer reviewed process. If you have valid and important arguments they won't just get ignored. In fact [DIP74](http://wiki.dlang.org/DIP74) faced a lot of criticism for not properly addressing escape checking first, that's one of the main reasons why we have DIP1000 now. The overall goal is also clear and has been stated ([Vision/2016H2 - D Wiki](https://wiki.dlang.org/Vision/2016H2#H2_2016_Priorities)), we want memory safe code w/o the GC.