On 08/22/2016 09:44 AM, Jacob Carlborg wrote: > It would be nice to have the whole picture now, before implementing > DIP1000. Then it's possible to review them together, making sure the end > goal is actual possible to achieve. Now we just have to trust Andrei and > Walter that all features will come together making the end goal > possible. We've already seen in the past that some features don't play > well together.
My understanding is that those are not supposed to be related in any direct way and danger of @trusted destructor is inherent to DIP1000 design (it should be better clarified in document itself though, see https://github.com/dlang/DIPs/pull/35) > I'm also not a big fan that the DIP is approved right from the start. > Then it's not a DIP, it's more of a FYI. It makes the whole process kind > of pointless since Andrei and Walter can choose to ignore the feedback. 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. I would personally prefer to see more of a commitee approach for validating such changes but that concept is far beyond available resources and community engagement. If both language authors agree that certain issue is urgent to solve than, in absence of formally written counter-proposals, there is no other way but to move ahead. Again, the DIP process is not for Walter or Andrei - it is for everyone else wanting to get their attention and submit good quality technical proposal. I hope authors of already submitted DIPs will improve them to required content bar and we will see how the process actually work but that is still to come. Note that during the meeting I did go through the list of all comments submitted through the community feedback to ensure that nothing was simply missed or forgotten and every issue is acknowledged. But all the decision making is 100% for Andrei/Walter in the end and I don't see how it can be different with existing state of affairs.
signature.asc
Description: OpenPGP digital signature
